>>Larry,
>>
>>Pure speculation on my part here, but I'd think that if either ODBC or OLE DB were used, that would provide a far bigger bottleneck than the string parsing.
>
>Hi George,
>I'm not sure I understand what you mean. I admit that ODBC being 16 bit would be relatively slow. But why would the 32 bit power of the OLEDB provider be a bottleneck?

SQLSRV32.DLL is the 32 bit driver for SQL Server 7.0. I've always assumed that the access was 32 bit. I digress, however.

The reason I mentioned this was a recent project I was involved in. My task was to create an in-process server that would: 1. Automatically map a drive to a server on our WAN. There were five servers to connect to. 2. Retrieve data from Fox free tables (style numbers). 3. Disconnect when a plant was completed. 4. Generate a distinct list of style numbers. 5. Remove all exitisting records in a style table in SQL Server 7.0. 6. Add all the distinct style numbers retrieved to the table. By far and away, the most time consuming part of this task was up-dating SQL Server. All told there were 23,000+ records gathered from the five plants (22 tables), with 11,000+ being unique.

To say our network isn't terribly swift is an understatement.

>IAC, I would probably go with the CreateProcess function and launch BCP to handle a new text file created based on the business rules.

I agree.