Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 535
  • Last Modified:

FM - Trouble with Mulitiple Imports

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
rvfowler2
Asked:
rvfowler2
3 Solutions
 
Will LovingPresidentCommented:
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
 
jvaldesCommented:
The only way to end up with duplicate records is to have "tenant Old" and "Tenant List" pointing to the same base table
0
 
rvfowler2Author Commented:
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
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
Will LovingPresidentCommented:
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
 
webwyzsystemsCommented:
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
 
rvfowler2Author Commented:
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
 
Will LovingPresidentCommented:
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
 
rvfowler2Author Commented:
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
 
rvfowler2Author Commented:
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
 
Will LovingPresidentCommented:
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
 
rvfowler2Author Commented:
Thanks for the tips, Will, I'll use them.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now