>Hey Bill,
>
>Clearly I like this part of your response the best...
>
>"For my concept though - not really wanting you to SPEND another dime -
>you should be able to retrieve the data via odbc and go forth. "
>
>I have really crude knowledge working with ODBC (I was able to set up a connection with FoxPro from Crystal Reports, so I get the idea). I don't know exactly which of the thousands of files in the manufacturing system contain the data. Then I SUSPECT I will need some sort of "permission" to connect with the server. I don't have a clue who/where I get this from. And the situation at the customer site doesn't offer me anything to go on. For now I'M their expert. I'm in the middle of the forest and I can't find any trees! I may be in way too deep here, but I don't have a clue even where they should turn.
>
>Thanks for your help...past and future :)
>
>Martha

Martha -
with VFP -
you need to make some kind of DSN for your odbc drivers -
could be SYSTEM DSN in the odbc manager - could be Connection String in vfp itself -
then
look at sqltables() and sqlcolumns() , with a scan..endscan on the output of sqltables, with a call to sqlcolumns inside the scan, making at *LEAST*
a collection of tables that contain the structure [via sqlcolumns] of each table that existed in sqltables().

However -that may not be all of the 'domain space' for that system - there may be more than ONE domain space to reverse engineer .

OK - so now you got the table names and the structure of each -
YOU STILL have to define where the data is stored and how - ie
what constitutes a bill of lading record, from a 'normalized' standpoint
and from an 'unnormalized' standpoint.

or - which table contains most of the line items for a bill of lading record, which table contains the master BOL, which table contains the customer INFO, which table contains the SHIPPER info, and which table contains the BOOKING info for that BOL, and MAYBE which table contains the contractual info and/or pricing for the Carriers that have contracts with that Logistics Company.
*whew*

not a trivial thing - I'm gonna assume the firm in question [that wrote the beastie] did not make the table space informative at all - and maybe will use some once-removed data dictionary table for lookups and record inserts -
i.e.
master DD table says table t416 is BOL line items
master DD table F415 table has the field/colulm definitions for table T416
t416 contains the BOL line items, and is positional in nature, with column names named F1...F82 [which are defined in meta back in table F415]

I ran across this techique several years ago when reverse engineering a Operational Support System written for an Oracle Backend - name O 'Remedy' .

My code worked UNTIL the DD got changed from rev 1.2 to 1.3 [big evil grin] /

Have fun ! Hopefully someone else here will supply you with some code snippets, but most of what I'm talking about has code examples ..

mondo regards [Bill]