We have an application that creates a number of Visual Foxpro (DBF) tables. Each of those tables have a different schema, but they all contain a known date field.
I've been asked to create another application (in C#) that will copy the last week's worth of data from each table to a new table (in a different folder to the source tables). The distinct tables will remain (e.g. if there are three source tables, there will be three destination tables).
Over time the tables may change (e.g. new fields added), so I can't make assumptions about table structure (apart from the existence of the aforementioned date field).
What's the easiest/best way to take the data from one table and create a new table with the same structure?
I know how to query the tables to extract the data (e.g. fill a DataSet with the last week's records). However, I'm thinking there must be a better way of creating a new table and filling it with the results than manually parsing all the field information in the schema and using that to recreate the the destination table.
Working with FoxPro seems to be different enough from SQL Server to give me a headache at each turn, so I need some guidance on my approach.
The production machine has the VFP 9 OLEDB driver installed on it. If possible, we'd prefer not to have to install much else.
You can simply do a:
as DRapp showed. However you may want to get indexes as well (if any) (BTW creating indexes via VFPOLEDB is not supported directly but you can do so using ExecScript() function). Then the easiest would be to copy the table's DBF, CDX (and FPT) files. VFP is file based.
Try something like this (note written in VB.NET and converted use www.developerfusion.co.uk/tools ):
To get an exact copy of the data, table, and records, you can do via a single SQL-Select via
Your where clause could be almost anything, and the Into TABLE clause tells the VFP engine to create the result set AS A NEW TABLE, so no need to explicitly declare types, columns, etc, query data from one and push into another...
One issue of consideration... Verify the user access to obviously be able to create, read, write wherever you are trying to create the new table. You can even specify a fully qualified path, such as C:\SomeOtherPath\Monthly\MyTable1 if need be...