HELP! Importing From Remote File Problems

[Tanya]

HELP!

In migrating my FM6 solution over to FM7 it seems that I have to specify the IP address in all scripts that use the "import records" script step if they are a client on a network with a remote server. This is terrible news for me as I use the solution for hundreds of different clients, all with different Server IPs. My question is:

A.) is there a way to specify that I want the import to simply look for the file's name (locally or remotely) - this is how it used to work in FM6

OR

B.) is there a way to make it based on a calculation that would go and look for the IP address of the server (if there is one)

[Bailey Kessing]

I just posted a similar discovery under servers. Seems like a really big bug. I also found that when you do specify the absolute path with the IP address to get these imports to work that it ignores the found set and imports all records in the source database. Did you find the same behavior?

[Deep Thought II]

i thought that's how "import" is supposed to work, no? such that it would import all records from the source file or whatever source it can be, since there is no option to choose to "filter" the particular records to be imported...

in the "Specify data source"... u can put in a list of filepaths or files in search order. it's rather odd for a program to try to search all network paths for a file by itself in this case~ no?

[Tanya]

No, this really is a major bug in FM7. We have now spoken with two rather high-up manager types at FileMaker support and they have said it is a bug being worked on in the next update. (Hopefully they know what they are talking about. Sometimes i feel like I know more about FM than they do.)

Yes, I experienced the problem with it only importing ALL records from a file. Seriously troublesome - the import script should allow you to select a specific found set and transfer those records from one file to another using "import." This is how it worked in previous versions of FM and is supposed to work this way now as it's the main way to move records from file to file.

Specifying the data source is not helpful for a commercial solution like ours (it may be fine for a one company solution) because we will be installing the same set of files for over 300 of our clients. These clients vary from one computer systems (no server) to 3 computer systems (no FM Server) to 30 computer systems (using FM Server.) We cannot build a solution that needs us to go in and enter the IP address for EVERY import script in the program (there are about 30 of them) for all 300 different clients.

Solution? We have decided (and were recommended to by the FM support managers we spoke to) to not use the import scrip step at all! We are using a work around which is much slower but works: we create a relationship between the two files based on an arbitrary serial number and have the program loop through the records in the main file, pasting info in to a portal to the related file to create new records there.

If anyone has a better solution I'd love to hear it. It really seems that FileMaker blew it on this one...

[-Queue-]

If you do a search on +import +bug, you'll find several threads where this has already been discussed.

[Deep Thought II]

arg, so what i thought it was supposed to work was a bug? heh...

well, my first Filemaker started with 7... so i never knew this is a bug at all...

[Tanya]

Although not a conversion ("migration") issue, the phenomenon of UNNAMED REFERENCES is discussed, as far as I can tell, only in the big migration white paper. (In the white paper, of course, they are supposed to work.) Unnamed refs are file refs that, rather than being stored in the file refs place (define file references) are stored in or with scripts (?). These orphaned file refs are created each time you use the "specify file" script step (import, open, etc) - thankfully not when using "perform script/external script" step. On a network, specifying fmnet:/IP/filename.fp7 works properly (i.e., correct file, file's current found set), but using the wildcard "*" [asterisk] in lieu of an actual IP results in what Bailey Kessing reports above (i.e., correct file, ignores found set). On a single machine, everything works like a charm, so developers get to wait until testing on a network to discover this zany bug.

I am recommending to my team that any time they see that "specify file dialog" when writing a script to think of another way. To see this bug (or some variant) in action, write a send mail script and try to specify more than one file as an attachment. The usual dialog states that one or more files can be specified with the add button or by typing paths. Even with an absolute path (IP, not "*"), files simply are not referenced beyond the first one.

This is a HUGE bug that FM seems to want to treat as a migration issue. It isn't. Make a fuss so we get a fix soon!

[Bailey Kessing]

Agreed, this is a major bug that has stop my FM7 development dead. I can't believe that they haven't sovled this immediately!!!