My application is running under AREV 3.12 on an NT network. I have a program that at one point exports data to a DB3 file. The export process is defined in IMPORTEXPORT and is called by a PERFORM command in the program. The problem is when the system message comes up saying that file already exits, do you want to overwrite it, when I say No, the data is lost. The target file doesn't change. I had assumed that the data would have been appended to the existing file. Where does the data go? Where should the data go? If the answer to the question to overwrite is NO, is there some way to capture that so I can display a message to the user letting them know that the data that was to have gone into that file has been lost or redirected?

So far I haven't found much in the way of information on the IMPORTEXPORT process. Is there someplace I read read up on this process in detail?

The message number on the message asking to overwrite the file or not is B105. When I say YES, overwrite the existing file, that happens just as I expect it to. It's the result from the NO answer that has me puzzled. Does anyone have any suggestions?

Thanks,

Michael Slack

As you've noticed "No" means abort. It just calls a standard message so you could use the feature of MSG that calls catalyst to prompt the user more meaningfully. There is no way in the export to append to a dBase file.

The Sprezzatura Group

[i]Celebrate CeBIT with Sprezz Local![/i]

I think the source code was included on one of the utility diskettes, but that may have been before the last change was made to the software.

It is possible to read & write a dbase file directly (using the dBeast bond) with normal RBasic syntax. It's not much more difficult than using export and is lot more flexible.

Thanks to everyone for your help. You told me what I needed to know.

Michael Slack

FWIW: I modified the export.db3 source from ARev v2.12 to write FoxPro v2.5 which have less restrictions than DBase III files (larger memo fields etc). FP v2.5 files are recognized by all of Microsoft's current products either through imports or the current MDAC components.

I also cleaned up the code from v2.12 (I couldn't find 3.x source for export.db3) to fix the Y2K problem in it (fixed in 3.x) and also a glitch in the memo field creation (would always create an empty memo frame and often create invalid memo files). This glitch is in the export.db3 included in ARev 3.12.

If interested I can email these to you.

Warren: I'd be very interested in these updates you've made, if you are interested in sharing them.

Thanks,

Jim

jjefferson@empiricadev.com

View this thread on the forum...