>>If you already wonder about 10**6 recs, allowing to export into dbf has running into the 2 GB barrier as next size problem. So think about SDF or CSV output of data if no Chr(13), Chr(10) values exist and XML it it does...
>
>Is the 2 GB barrier only applicable to VFP or to any other environment capable of reading DBF?

Strictly spoken for vfp a 2GB limit exists for each file type (dbf plus fpt allow more payload). Similar barriers exist in other old variants using the .dbf format, some new variants like Advantage or Lianja allow larger amounts of data. There the structure of each record in the .dbf-file is very often identical and only minimal differences in the dbf-header exist. It might be possible for other products to import a vfp-formated file with a reccount manually set and records added via filehandling API - but even testing for that IMO makes no sense, if other formats allowing bulk loading exist.

Writing out larger amounts of data to correcly set header/record-payload files with such tools as Advantage should be possible with no or minimal amount of code change by utilizing ADO.Net components for that format and the already existing code you hinted at in reply to Bill.

As dbf is well-defined, fast loading and efficient when zipped it is for me a nice and preferred exchange modus, but having the tools at hand with CSV and SDF for other systems or export data growing beyond vfp limits is possible even working within vfp-limits itself with some forethought by chaining such files together. If you have currently no need for that and existing code to export dbf, fine, but if your export sizes grow, having support for simple text files in place is nice as you can *always* offer to pipe your data into such a format while you discuss giving them the format they need if you do not already support it. Keeps the door open when discussing with IT groups eager to do the stuff their managment wants from *you* themselves...