Hello everyone, I've spent months on trying to figure this one out on my own. I have a table with over 2,600 records. It can take up to 10-15 minutes to import one record, because thats all i need. Basicly its a purchase order database. The buyer types in the part #, then presses the import button, and fm starts to import the fcst and description ,etc for the item. Well, I just need it to import that matching values for this item, not import all of the 2,600 records, then drop the values it needs. Is there anyway to import just the item number that matches whats been put in the part # box?

I would say yes, just make a found set, since only the found set gets imported ...but it seems to me that the relational structure is somewhat iffy ...why import in the first place???

--sd

Hello SD, I'll have to figure out what you mentioned about the found set. The reason we import is to import the forecast, and pos data and delivery data etc. I've been thinking about using lookups for this, but will lookups update past records as well, I dont want that to happen. Hmm.

Do a search of the help file for "lookup". They are designed to efficiently do what you are trying to accomplish with your import script. They Look-up information when you enter your part #, as long as you dont re-enter/change old records (or force a relookup) the Lookup fields will not have their values changed. This way you can say.... update the price of an item so on all future orders the new price will be entered but your older records will not be changed.

But lookups as well as imports have 2NF breaking syncronizations, why can't unstored calcfields over the relations be utilized??

--sd

But lookups as well as imports have 2NF breaking syncronizations, why can't unstored calcfields over the relations be utilized??--sd

I have no idea what "2NF breaking syncronizations" means???

Why would you use calculations over the realtionship? What happens when the description of your product changes slightly, or the number of items per case changes, or ..... In our case we don't want the older orders to reflect the changes, we only want new orders to reflect those changes.

The data in calculation fields can not be entered and modified which would propose problems for our Purchase Orders. Lookups are more versatile for our needs so that when an unforseen situation arises the data can be modified to conform to the situation at hand rather than for all past and future orders.

I'd go with the lookups in this case, as product information could change over time, but the PO should reflect what it was at the time the PO was created.

This is just great, it worked like a charm. The previous person handling File Maker Pro here was a wiz, I have no idea why she was importing for over two years, look ups work perfect, and you guys are right about the import problem, it was changing past information. You guys are the bomb we they say!

but the PO should reflect what it was at the time the PO was created

Thats the tough thing about foreign languages ...abbreviation!!

What I wondered about was why moving information and not key in the first place, but if we're talking lines in invoices ...are lookups the thing - pre 7!!!

--sd