Problem with Scripted Import When File is Shared, but Not When It'sSingle-User

I have a strange problem with a scripted import in a file in FM 9.0v3
on FM 9 Server. The file is multi-table, but for the purposes of this
script, only one table is used. Essentially the script does the
following:

1. Asks a user to identify a CSV file that has been downloaded from a
website
2. Error-checks to make sure the user has done this correctly
3. Imports the data into about a hundred fields
4. Parses the data to distribute it to certain fields and replaces
errors and inconsistencies
5. Tells the user that everything went splendidly.

On a single-user file this does, in fact, work perfectly. But on
multi-user files, not so much.

The error-check in Step 2 looks for three things after the Open File
dialog: either the user has canceled the action (error code = 1); the
import order is invalid ( = 409); or any of a number of import
problems such as wrong file type ( > 700). For some reason, a
perfectly valid CSV file that is correctly imported when the database
is in single-user mode returns error code 409 on when it's served from
FM server. Nothing has changed but that one thing. In fact, when I
disable the step that checks for error 409, the script fails to import
any data and behaves the same as if the file was an empty document. In
the import step itself, I've checked "perform without dialog" and
"specify import order" (UTF-8, matching field names), but not "specify
data source." This is to reduce user confusion, since the data
source's file name is different every time.

Any ideas? The crucial piece of information above is that the script
works perfectly on the database when it is not being shared, so
suggestions that don't take this into account will probably miss the
target.

Thanks as always for putting your heads to this.

Best,
-J.

No ideas of what might be going wrong off the top of my head. But try this:

Set the script's import step to not hide its dialog. That way you can
step through the import mapping to either make sure it is still correct
or to see what might have gone wrong.


jahn wrote:
> I have a strange problem with a scripted import in a file in FM 9.0v3
> on FM 9 Server. The file is multi-table, but for the purposes of this
> script, only one table is used. Essentially the script does the
> following:
>
> 1. Asks a user to identify a CSV file that has been downloaded from a
> website
> 2. Error-checks to make sure the user has done this correctly
> 3. Imports the data into about a hundred fields
> 4. Parses the data to distribute it to certain fields and replaces
> errors and inconsistencies
> 5. Tells the user that everything went splendidly.
>
> On a single-user file this does, in fact, work perfectly. But on
> multi-user files, not so much.
>
> The error-check in Step 2 looks for three things after the Open File
> dialog: either the user has canceled the action (error code = 1); the
> import order is invalid ( = 409); or any of a number of import
> problems such as wrong file type ( > 700). For some reason, a
> perfectly valid CSV file that is correctly imported when the database
> is in single-user mode returns error code 409 on when it's served from
> FM server. Nothing has changed but that one thing. In fact, when I
> disable the step that checks for error 409, the script fails to import
> any data and behaves the same as if the file was an empty document. In
> the import step itself, I've checked "perform without dialog" and
> "specify import order" (UTF-8, matching field names), but not "specify
> data source." This is to reduce user confusion, since the data
> source's file name is different every time.
>
> Any ideas? The crucial piece of information above is that the script
> works perfectly on the database when it is not being shared, so
> suggestions that don't take this into account will probably miss the
> target.
>
> Thanks as always for putting your heads to this.
>
> Best,
> -J.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg
FM Professional Solutions, Inc. Los Angeles

FileMaker 8 Certified Developer
Member, FileMaker Business Alliance

Howard, that was an excellent idea. If I'd thought of it, it would
have saved me lining everything up by eye when I was running a test
earlier. But alas, it didn't give us much to go on: the Import Field
Mapping dialog shows a perfect match between source fields and target
fields; the other records in the source file are all there; the import
options dialog appears -- and then I get error 409. It's so bizarre.
Any ideas? Anyone? Anyone?

On Tue, 19 Aug 2008 22:02:01 -0700 (PDT), jahn
wrote:

>Howard, that was an excellent idea. If I'd thought of it, it would
>have saved me lining everything up by eye when I was running a test
>earlier. But alas, it didn't give us much to go on: the Import Field
>Mapping dialog shows a perfect match between source fields and target
>fields; the other records in the source file are all there; the import
>options dialog appears -- and then I get error 409. It's so bizarre.
>Any ideas? Anyone? Anyone?

Make sure the file paths and/or references are valid. The path to a
file that your user browses to locally, with the database opened
locally (not shared), is probably not going to work when the databese
is shared, even if the client and server are the same machine. FMP
has a very specific syntax for file paths; make sure yours are valid.
Also, it's best to express file paths as network shares, even if the
machine in question is the host.

If the file path doesn't change, just the filename does, set the path
as a variable at the start of the script. Then, when your user inputs
the source file/path name, set that as a second variable. Create a
third variable by concatenating the first 2 and send that to the
Import Records dialog instead of a text string.

hope this helps

--
FW

FileMaker Pro 8.5 Advanced on Windows XP Pro SP2
FileMaker Server 8.0 on Windows 2003 Server R2

Hi, FastWolf, thanks for the input. Paths are definitely an area I've
had trouble with before (FM uses different syntax for different Get
functions), but I'm pretty sure that's not the problem here. That's
because: 1) the user is asked to locate the file via FM's Open File
dialog, so no path is described; 2) when I uncheck the "Perform
without dialog" box, the Import Mapping dialog appears with the source
file on the left side clearly displaying the records, so there's no
question the database is opening the file and, so to speak, _seeing_
it. But somewhere between the mapping dialog and the actual import,
it appears to forget that it's just seen the records and decides
there's nothing there. Kind of like computer Parkinson's or
something.

Okay, here's something ridiculous: I just tried to run a test on the
file to see how it would behave if I specified a data source in the
script and the import worked without a hitch. Then I tried it with
the original settings -- no data source specified -- and it worked
then too. Then I ran it with all my error-checking steps taken out
and it worked again. In other words, it's working now, even though it
hasn't for the last 36 hours.

I guess that's kind of a solution, but wtf? I don't know what to tell
you. I've been hammering at it for hours and nothing has changed that
would make it function properly now. Perhaps a gremlin.

Thanks for all the input.

Best,
-J.

On Wed, 20 Aug 2008 18:28:22 -0700 (PDT), jahn
wrote:

>Hi, FastWolf, thanks for the input. Paths are definitely an area I've
>had trouble with before (FM uses different syntax for different Get
>functions), but I'm pretty sure that's not the problem here. That's
>because: 1) the user is asked to locate the file via FM's Open File
>dialog, so no path is described; ...

A path is most definitely expressed. How else is FMP going to find
the file? This is what I'm trying to tell you -- the differences
between local, relative, absolute, and network paths here are crucial.
If the local folder containing the CSV is on a network share, that's
at least 2 possible paths to it from the same local client. Use the
network path. You're better off telling the system where to look
using a variable if at all possible.

>... 2) when I uncheck the "Perform
>without dialog" box, the Import Mapping dialog appears with the source
>file on the left side clearly displaying the records, so there's no
>question the database is opening the file and, so to speak, _seeing_
>it. But somewhere between the mapping dialog and the actual import,
>it appears to forget that it's just seen the records and decides
>there's nothing there. Kind of like computer Parkinson's or
>something.

Have you verified the integrity of the source file? Open it up in a
plain text editor and take a look at the data themselves, not just the
fieldnames. Maybe your file's munged.

>Okay, here's something ridiculous: I just tried to run a test on the
>file to see how it would behave if I specified a data source in the
>script and the import worked without a hitch. Then I tried it with
>the original settings -- no data source specified -- and it worked
>then too. Then I ran it with all my error-checking steps taken out
>and it worked again. In other words, it's working now, even though it
>hasn't for the last 36 hours.

But is it working when shared as well as when local? And are you sure
the source file is the same version as before? How many users are
working with these data? For dev purposes you need total control of
the environment.

>I guess that's kind of a solution, but wtf? I don't know what to tell
>you. I've been hammering at it for hours and nothing has changed that
>would make it function properly now. Perhaps a gremlin.

It's a repair, but it's not a solution. The only gremlins I know of
were built back in the early 1970s by American Motors Corporation and
they were strictly analog mechanisms. Like most scripting/computing
issues, this one is likely a case of GIGO.

hope this helps

--
FW

FileMaker Pro 8.5 Advanced on Windows XP Pro SP2
FileMaker Server 8.0 on Windows 2003 Server R2

Hi, FastWolf -

"GIGO" is a bit strident, I think. This is a friendly group and we
try not throw insults around. If you read my posts, you'll see why
your comments about path expression and the integrity of the source
file have already been addressed. If you can't find you're answers
there, well, then, I can't help you: it's a matter of not paying
attention to the information provided.

-J.

On Thu, 21 Aug 2008 09:51:53 -0700 (PDT), jahn
wrote:

>Hi, FastWolf -
>
>"GIGO" is a bit strident, I think. This is a friendly group and we
>try not throw insults around.

Oh for heaven's sake ... Look, I'm not proud -- if I offended you in
any way then I apologize, right now. I intended the term GIGO to
represent the zero-tolerance way computers and software operate,
that's all. No reflection upon yourself was intended at all. As a
matter of fact you come across as a intelligent and experienced person
and I for one would like to make sure you feel welcome here. If
anything I was referring to my own tendency to GIGO (I think we all do
that at at times).

>If you read my posts, you'll see why
>your comments about path expression and the integrity of the source
>file have already been addressed. If you can't find you're answers
>there, well, then, I can't help you: it's a matter of not paying
>attention to the information provided.

I have read your posts, very carefully. In my experience, one needs
to make ABSOLUTELY sure the really basic, obvious things are correct
and working first, before looking for more esoteric answers, because
in the vast majority of cases that's where the trouble is. Especially
in this case where no one can seem to reproduce the issue you're
having. Not knowing your experience level with FMP I tried to provide
some fundamental information that spoke directly to the kind of issue
you have. If it was redundant, it was still worth doing. Sometimes
one must go over the same things over and over and over again before
seeing where the problem is. It's just that I've had FMP issues where
I was saying the same things you are, and later discovered I was
wrong. Oh yeah.

best regards, and

hope this helps

--
FW



>-J.

FileMaker Pro 8.5 Advanced on Windows XP Pro SP2
FileMaker Server 8.0 on Windows 2003 Server R2