Roger,
We have a lot of printouts that have a special export to excel, where we actually build the data to a work file and export to a fixed file (excel file) for the user to review the data, especially in our accounting module. There is a problem if the user decides to do another one with different selections (dates,etc) and leaves the excel spreadsheet open. I know to resolve we could use a different file name each time, or let the user assign one, but we prefer to not clutter up the export folder, and not require the user to enter a file name each time.
Do you know of a method to check to see if the excel file can be written to and opened and bypass the file write errors they are getting. We do have this occur a few times a week (error messages emailed to our support desk) and the user eventually figures it out, but we need to fix it one way or another.
Thanks, and have a great Turkey day.
Fred
Omni
Excel Export Question
Re: Excel Export Question
Klaus has the right idea.
Fopen() will return a handle greater than 0 if the file can be opened.
It will return 0 or -1 if not.
Make sure to close it with FClose().
Fopen() will return a handle greater than 0 if the file can be opened.
It will return 0 or -1 if not.
Make sure to close it with FClose().
The eXpress train is coming - and it has more cars.
Re: Excel Export Question
I could not get that to work right, but something close worked. I first checked to see if the file existed, then used ferase(). If it failed, then created a random file name. It works.
Thanks for leading me in the right direction.
Fred
Thanks for leading me in the right direction.
Fred
Re: Excel Export Question
Hi, Fred.
That may lead to the situation that a user has this file(name) in his Excel-file-history and fails at the attempt to open it again. FOpen() with FClose() avoids this.I first checked to see if the file existed, then used ferase().
Best regards,
Tom
"Did I offend you?"
"No."
"Okay, give me a second chance."
Tom
"Did I offend you?"
"No."
"Okay, give me a second chance."