Steve,

So, it sounds like you can basically do any sort of COM automation from your script...so, how about calling VFP as a COM object and having it do the pack on your DBC?

Try something like this (code is in VFP...you will have to modify to match whatever WSH wants to see):

oVFP = CREATEOBJECT('VisualFoxpro.Application.6')
oVFP.DoCmd('OPEN DATABASE EXCLUSIVE')
oVFP.DoCmd('PACK DATABASE')
RELEASE oVFP

Not sure of just releasing the VFP object is the proper way to clean up, but issuing a 'QUIT' didn't seem to be allowed...

Anyway, I used VFP 7.0 to fire up the above instance of VFP 6.0 and was able to pack a database that way.

Does this sound like a viable option? You will need to have VFP installed on the machine you are using to run the scripts, and will have to have file access to the DBC in question. I guess if you had that you could just use VFP to do the pack directly, so I am assuming there might be a problem with this idea...

Good luck!

JoeK

>My whole thing (maybe it will help someone else out there do something one day):
>
>I have a decent-sized VBScript that I am executing nightly with cscript.exe. It uses MSXML4 to talk to the SQLXML provider behind a firewall, pulling in XML which I then convert to a local VFP DBC. The routine is:
>
> 1. Using a SQLXML template, get the table/column info from the Information_Schema.Columns table on MSSQL. This comes back as XML via the SQLXML ISAPI filter.
> 2. For each node that comes back, parse the XML string containing MSSQL column types into appropriate VFP types and parse the MSSQL table name to a legal/liveable VFP name.
> 3. Create a VFP table in the local DBC with the new name.
> 4. Drop the existing VFP table
> 5. Run a series of ALTER TABLE commands to create a new VFP table.
> 6. Using a SQLXML template, retrieve the MSSQL table as an XML document (breaking it into 1000-row result sets for known large tables to keep mem/CPU usage low)
> 7. Parse each XML node into an Insert-SQL statement, doing an insert for each row.
> 8. Index certain columns of the result VFP table.
>
>This is for an app server where constant lookup table querying is done. In the previous version of the app, the web server went to MSSQL with ADO/OLEDB for every lookup. This was slow and not all that secure since COM needs a lot of open ports on a firewall. So instead, the the SQL-Select can be done against a VFP DBC on the local filesystem (there's nothing faster or more scalable). The lookup time for the lookups has dropped from 20-70 seconds (variance due to other architecture issues) to 1.
>
>Anyway, it's step 4 that is bloating up the DBC. It seems like every time I drop a table the deleted() mark gets put in there. And with 25 lookup tables done every day, the DBC is bloating up fast. I was thinking that I might create a seperate script (to run weekly) to copy the DBC/DCT/DCX to a DBF/FPT/CDX and then connect to the temp DBF with the OLEDB driver and issue a PACK and then copy the files back over the originals. But I'm not sure I can do that with OLEDB. I wish I could just PACK DATABASE but it doesn' look to be that easy....
>
>Comments welcome!