Most likely you do not have access to the file path when you are trying to run this on a server.
Can you post what your path to the file looks like? It should be in the server documents folder, calculated something like this:
"file:" & get(documentspath) & "yourfile.csv"
Server edition has limited access to file paths, the documents path is most reliable.
You can run a system script (.bat batch DOS file) to move a file from one path into the documents directory if you need to prior to running your import. I do not have an example of that handy, but I think it uses the COPY, MOVE or XCOPY command from DOS.
Mike, thanks for your reply.
In your reply, are you referring to
-- the Source file (.txt file on the local worksation) or
-- the Target file (the FM12 db on the server)?
This issue is for another, so I can't see their paths.
That user IS able to read and write to the FM12 db on the server from her worksation,
but unable to Import the data from the .txt file that is local on her worksation.
When I test the Import from my own setup
... using FMProAdvanced on Host and Workstation
... using exact copies of her Target and Source files
... workstation path to Host: fmnet://IPAddress/File\Name.
... .txt file data Imports from the workstation
Are you saying that the problem is that the FM12 server is running Windows Server 2008?
Are you saying that the .txt file needs to be on the server before it is Imported to he FM12 db on that server?
... more help, please.
I'm not saying the problem is your server, or that the txt file needs to be on the server. You said it worked when it (your .fmp12 file) was local but not hosted, so I figured you were trying to run a server scheduled script to import the data. Also, given the large field count, I figured you had scripted the import to save time.
If the error is occuring when a user manually tries to run the import, and manually is selecting the file, then there are two likely causes.
1) Permissions issue, EG the user does not have permissions to create records in the target table, or does not have permission to import.
2) File format issue. I suspect this might be the case with your file, given that 360 fields is sort of an absurd amount to go into a single table. CSV/TXT files get flaky the more fields you add, but if you can say without a doubt that you've tested the exact same source file for import, it might not be this.
Unfortunately the error is thrown for numerous reasons. Read through some other user's causes here:
If anything pops out that seems like it's similar to your setup, try getting around that. There's not a lot you can do without seeing the setup of the user for yourself.