I'm having trouble appending new records to an existing database using the trial version of FMP. I've tried In Browse mode I select Add New Records from the File menu, and have tried using every Import Action (Add New Records, Replace Data in New Found Set, and Update Matching Records with/without Add Remaining Records checked). Every time, all the records in the existing database are replaced by the new ones, instead of being added to.

That is not normal. Are you sure that your original records are really disappearing or are they just disappearing from the found set? After you do an import, do a "Show all Records." Normally, after an import, only the records imported will show up in the found set, but the rest of the records are still in the file.

Plain Import will just append all imported records and place that as current found set.

Check the number of records before and after the import.

I am probably talking to your ankles, but here goes anyway.

Check the setting for each field on Import. Make sure you don't have the MATCH FIELD set on a field. That's how you set the other fields to IMPORT into current records. I would Export a file from your database to verify the structure and then import it back. Your number of records should double.

Check them and then delete all found records.

Larry

It might be a feature of the trial version. Perhaps you have exceed the trial version record limit?

Hi Vaughan,

The only limitation that I have found in the Trial (Demo) Version is the 30 day period.

I have tested it in numerous ways, including the things that FMPoppa was having a problems with, and have not found any bugs, or limitations such as this.

HTH

Lee

That's pretty generous of FMI, only putting in a 30 day limit.

Although... from the Help file for Status(CurrentError) function, FMP 6.0v4 Mac OS X: Error 403 = "exceeding maximum record limit for trial version of FileMaker Pro." A record limit may have been built into the trial version at some stage, but later removed.

I've never fiddled with FMP Trial versions for any appreciable time, so I'm prepared to take your word for it, Lee. You never did me no wrong before.

Vaughan said:A record limit may have been built into the trial version at some stage, but later removed.

Yep, that's correct Vaughan. Earlier versions had a limit of 50 records in the demo version. The current version is 30 days full functionality.

It might be 'generous', but I think it's more likely just strategic. I think it may have occurred to the the folks at FMI that the more records a user puts in during the 30 day trial, the more the user has to lose if they decide not to shell out for a licensed copy when the demo expires.

Thanks to all of you for being so willing to help. Bob gave me the answer right away, just couldn't get back to post b4 now. For some reason, although the FileMaker Pro 5 Bible that I grabbed from the local used bookstore does mention Found Sets in ch. 9 (Searching/Selecting Records), there's no reference to it in the Importing Records section of ch. 16 (Exchanging Data Between Applications) that I referred to for directions. 30 days *is* a very generous trial period considering that FMP doesn't appear to be crippled in any way, but I suspect that the learning curve (especially for a dunce like me) is a bit longer. LOL.

Well, according to another discussion going on in another section of this forum, it's possible to learn Filemaker in 24 hours.

Yeah...

Get in touch with that jfmcel character:

http://www.fmforums.com/threads/showthreaded.php?Cat=&Number=80212&page=&view=&sb=5&o=&vc=1

I hear *he* can tell you all there is to know about filemaker in only 30 mins!

Hi,

On the subject of importing records, could anyone help me with this one...I have developed a runtime solution that exports data in a tab delimited format. These files then need to be imported into a FMP solution on a weekly basis and there will be about 40 files in all. How can I automate the import process (Applescripts scare me)?

Thanking you in advance

Paula

Hello Paula,

Welcome to the Forums!

What you are trying to accomplish can be done without the aid of AppleScript - you can achieve it using FileMaker scripts alone.

What I suggest that you do is:

1. Create a script within each of your 40 files which imports the contents of the appropriate tab delimited file (sourcing it with a predetermined file name from within the parent folder for the FM solution). As FileMaker scripts save the most recent import order and settings, you'll have to perform the import manually in each database immediately prior to creating the scripts. Make sure that the import script steps are all specified as 'No dialog'. Aslo make surfe that none of the scripts are set to appear on the scripts menu

2. Create a master script in your main FileMaker db which performs each of the import scripts in turn (calling the other 39 as external sub-scripts. This one script can be attached to a button and/or included on the scripts menu.

Once this is in place, you need only place a fresh set of tab-delimited files from the runtime into the FileMaker solution folder (keeping the names of the files the same each time - and therefore overwriting any previous set) and then run the script in the main file. The content of the tab delimited files will then be imported - each in turn - into their respective counterparts among your 40 solution files.

Ray,

Thank you!

And thanks for your help. I've no doubt that it'll all work perfectly if only humans didn't have to have any interaction with the db!

Paula

Paula said:...I've no doubt that it'll all work perfectly if only humans didn't have to have any interaction with the db!

Paula,

If human error is likely to be a factor, you can do a great deal to anticipate it and correct for it by building appropriate error handling into your scripts. So for instance, you can test for an error after each import step and if an error is returned (meaning that the file was not found for instance) you can have the script:

1. report the exact error condition to the user, and

2. call a sub-script which reverses all the import procedures to date, returning the whole file set to the state it was in before the first import script ran.

You can't prevent human error, but you sure can get the jump on it.

Ray,

I've been trying to find holes in your suggestion since this morning but can't see any. You have given me the idea of creating an intermediate file to import clean accurate data, incorporating your suggestions and when that is complete, import the data into the main file (while deleting it from the intermediate file).

Brilliant! Thanks,

Paula

That's a technique I use frequently, Paula. It requires a bit of extra work to set up, but can have a number of advantages in some situations.

One thing to look out for though, is the possibility that opening the intermediary files will result in your solution exceeding the limits on maximum number of files open at one time.

There are two things to do about this. One is to test for an 814 error ('file(s) cannot be opened because maximum number is open') on calling trhe external script. The other is to ensure that you script each intermediary file to close before opening the next one, so that you only ever have one additional file opened at a time.

With a solution of 40 or so files, it may be wise to include both provisions in some form.

I am having a similar problem with the import/export process. I want to have my script export the selected records into another FM file, but when I set up the script and try it out, it replaces the 2nd file with a new file each time. Is there a way to have them added to the 2nd Dbase?

Liz said:

Is there a way to have them added to the 2nd Dbase?

Yes.

Have your script do the following:

1. find the records your want to 'export to the other database. then

2. call an external sub script in the other database which imports the records

That way the records will appear in the existing (2nd) database, in addition to any records that are already there.