Solved

FM - Trouble with Mulitiple Imports

Posted on 2011-09-28
11
520 Views
Last Modified: 2012-05-12
I am having trouble with the following script.  It is not consistent.  If I run it with Script Debugger, it works fine; however, when run manually, it only imports about 25 records about every other time instead of 600+ to the old table.  In fact, once in the new table, I got twice as many records as expected.  The only difference I can see is the script runs faster than in Debugger.  Is there any known problem with deleting records or importing too fast?  Thanks.  See code attached. Multiple Imports script
0
Comment
Question by:rvfowler2
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
11 Comments
 
LVL 25

Expert Comment

by:Will Loving
ID: 36812725
Randy - I don't see anything odd about the script. Is there anything you can tell about what's being imported? Are the 25 records random or the first or last? Is it possible that it's importing from the wrong file, a different one that you think it's using that may only have 25 records in it? I would compare the import file to what get's imported and see what you can tell from that.
0
 
LVL 9

Expert Comment

by:jvaldes
ID: 36812888
The only way to end up with duplicate records is to have "tenant Old" and "Tenant List" pointing to the same base table
0
 
LVL 2

Author Comment

by:rvfowler2
ID: 36815565
First, Tenant Old is a copy of Tenant List, so its a completely different table.  Second, Will, checked the import screens (see attached) and they seem OK.  And, if it is doing it correctly every other time, then I can't see how it is importing from the wrong file.  I even added "Show All Records" before deleting them to ensure I deleted all the records first.  
 Import1 Import2
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 25

Accepted Solution

by:
Will Loving earned 400 total points
ID: 36815693
Ok, you're currently using Last Order. That works fine as long as both your FM table and the file you are importing never change fields. What I usually do it make sure the Import file has a header row with the exact field names and then use "Matching Names". Using last order is prone to issues if you happen to delete an unneeded field or otherwise change things in either the Import file or FM. With Matching Names, you only have to worry about keeping  the field/column names in sync. To use matching names, you do need to have the "Don't import first record..." checkbox ticked.

I'm not sure if this is related to your problem but I would consider changing it.

By importing the wrong file, I meant to look at the save File Path for your Import file and make sure it's where you think it is and also that the process of creating that Import file - I think you said you used a .bat process? - is working consistently. If it brings in only 25 records, make sure that the import file is correct and has more than 25 records in it.
0
 
LVL 10

Assisted Solution

by:webwyzsystems
webwyzsystems earned 100 total points
ID: 36816162
This almost sounds to me like there is something inapplicable about the context in which you use your tables and layouts.

I think the context is different when you execute within the script debugger. You have no "current record" selected upon which other values might be looked up. So...everything would be determined at run time, all records selected and deleted.

Without the debugger though...are you moving to a layout where the table occurence is pulling related values somehow? So - show all records would only show the related ones - which means not all of them would be deleted.

You could setup a global field where you can write out some debugging information.

Then, in your script - just write to the global things like Get(CurrentFoundCount) to see really how many records are being deleted.
0
 
LVL 2

Author Comment

by:rvfowler2
ID: 36816365
The TO is simple a one-to-one relationship and everything in the Old table should equal the new, save a couple of vacancies that may have been deleted or added.  The number should only be off by a couple.  I think the problem was with the last order, but not in the import from the txt file.  (However, it probably would be a good practice to change this.)  I changed the import from the New to the Old from Last Order to Matching Names (which I thought I had already done).  After this, I have had no problems.

Also, a clarificaton.  If my cursor is on a record when I run the Script Debugger, isn't there a record selected?  I thought the Debugger exactly reproduces what you would do with a manual run of the script (though not reproduce what a scheduled script off the server does).  Thanks.
0
 
LVL 25

Assisted Solution

by:Will Loving
Will Loving earned 400 total points
ID: 36816398
In my experience the only time the debugger functionality varies with actually running the script is when testing a networked system and doing something that involves changes in a related table and the appearance of those changes elsewhere such as in a portal or a calculation field in another table that references those field. Because the script debugger goes through things more slowly, it seems to sometimes inadvertently trigger or allow for a Refresh across the network that might not take place of be visible to the end user when running the script without the debugger.
0
 
LVL 2

Author Closing Comment

by:rvfowler2
ID: 36816848
Will identified the problem with Last Order, but giving some credit to WebZ for info I could use on future debugging.  Thanks to all.
0
 
LVL 2

Author Comment

by:rvfowler2
ID: 36925228
FYI, had a similar problem again.  Turns out it was NOT selecting matching for the type of import, but something else.  Notice in the script steps above that I needed to have a Show All Records BEFORE I move to the old table because I remembered that the import script step only imports the Found Set.  I also added the layout to ensure the Show All applies to the correct table/layout.
0
 
LVL 25

Expert Comment

by:Will Loving
ID: 36925289
Generally speaking, if I'm importing by script, I always start with a layout for the records to be imported and have a Show All Records script step. I THEN open a NEW window to a layout for the table the records are going to be imported into. This seems to be the most reliable in terms of the import getting ALL records rather than the last found set. I also make sure to only have 1 window open for the table that the records are being imported FROM.
0
 
LVL 2

Author Comment

by:rvfowler2
ID: 36925301
Thanks for the tips, Will, I'll use them.
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Problem: You have a hosted FileMaker database and users are tired of having to use Open Remote or Open Recent to access the database. They say, "can't you just give us something to double-click on rather than have to go through those dialogs?" An…
Having just upgraded from Filemaker 11 to Filemaker 12 over the weekend, we thought we would add some tips for others making the same move.  In general, our installation went without incident. Please note that this is not a replacement for Chapter 5…
Nobody understands Phishing better than an anti-spam company. That’s why we are providing Phishing Awareness Training to our customers. According to a report by Verizon, only 3% of targeted users report malicious emails to management. With compan…

734 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question