Weird Issue During Excel Export
Hello,
I'm encountering a weird error that we seem unable to resolve. I have an MS Access application that exports data into an Excel worksheet and formats the worksheet to look like a Gantt chart. This process has worked great for years across multiple OS's, processor types, etc.
I recently deployed this application at a new client and it is not working properly. The back-end is in Azure, SQL Server 2012. The front-end is in MS Access 2013 and works great in my environment no matter how many variations of VM's I create to test it, and it also works great for the client's IT machines.
However, the report/export does not work properly on the machines of the end users. Basically, it stops formatting altogether around column "IK" (245). After that, it no longer can set column widths, merge cells, add borders, etc.
Any thoughts on what might be going on?
I'm encountering a weird error that we seem unable to resolve. I have an MS Access application that exports data into an Excel worksheet and formats the worksheet to look like a Gantt chart. This process has worked great for years across multiple OS's, processor types, etc.
I recently deployed this application at a new client and it is not working properly. The back-end is in Azure, SQL Server 2012. The front-end is in MS Access 2013 and works great in my environment no matter how many variations of VM's I create to test it, and it also works great for the client's IT machines.
However, the report/export does not work properly on the machines of the end users. Basically, it stops formatting altogether around column "IK" (245). After that, it no longer can set column widths, merge cells, add borders, etc.
Any thoughts on what might be going on?
MajorBigDeal
Without doing any debugging, a wild guess would be that it is a memory constraint. I know that historically Excel has been very sensitive to the amount of available RAM. Is the a difference in the amount of RAM on the machines where it works vs the machines where it does not work?
ASKER
That was a thought I had too, but those users have 4GB. Shouldn't that be enough to handle a spreadsheet?
Does the destination spread sheet already exist, and you only modify it, or does it create a new excel sheet? I ask because I suspect the destination excel, if modified and not created at run time, may be corrupted.
ASKER
It's created at run-time and saved after it's finished being created. I supposed I could try saving it first and then formatting it?
LOL, I would think that 4GB would be enough. I think this is one of those situations that might benefit from some creative debugging by trying to create some boundaries to the problem in the hope of generating some clues.
How many different end-user machines do you have available for you to try this on? Are they all configured identically? Do any of the "end users" have admin rights on their machines? the idea being to see how consistent the misbehavior is.
Also, can you reduce the amount of data in each column but still leave the same number of columns? The idea being to see if the place where it starts acting weird stays the same or changes.
Can you check to see how much of the end-user RAM is used and how much is available?
Can you look at the windows event log after you run this to see if it is complaining about anything?
Have you looked at the processes of the end-user machines to see what they are running and if any of it looks unusual?
How many different end-user machines do you have available for you to try this on? Are they all configured identically? Do any of the "end users" have admin rights on their machines? the idea being to see how consistent the misbehavior is.
Also, can you reduce the amount of data in each column but still leave the same number of columns? The idea being to see if the place where it starts acting weird stays the same or changes.
Can you check to see how much of the end-user RAM is used and how much is available?
Can you look at the windows event log after you run this to see if it is complaining about anything?
Have you looked at the processes of the end-user machines to see what they are running and if any of it looks unusual?
ASKER
I removed the data and only did the formatting (merge, forecolor, backcolor, etc) and it still failed at the exact same point. Also, we tried it on one of their more powerful machines in the office with 12GB of ram and it still failed at the same point.
We've tried various combinations of being admin/non-admin, on/off the domain, etc.
We've tried various combinations of being admin/non-admin, on/off the domain, etc.
Hmm, I'm starting to suspect thier network and servers. Is anything that might be related showing up in the logs on those machines (azure and SQL hosts) when you run the process?
Is it possible to test with a local datasource? (I know you said you removed the data- does its still talk to azure and SQL though?) Or perhaps you can test running the program directly on the servers?
Is it possible to test with a local datasource? (I know you said you removed the data- does its still talk to azure and SQL though?) Or perhaps you can test running the program directly on the servers?
ASKER
I'm waiting to hear back on the logs. The reason the database is in Azure is because they don't have a SQL Server environment.
However, when the formatting process fails the data is still entered, the spreadsheet just looks horrible.
However, when the formatting process fails the data is still entered, the spreadsheet just looks horrible.
I think that the fact that it fails consistently at the same point is good news because it should make it easier to crack the problem. Can you try removing one type of formatting (but leave the others) and see if you can get it to behave any differently? At some point, it has to start working again and the you will have a boundary to work with.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Wow, good catch, I never would have thought of that. What format WAS it using by default?
ASKER
Excel 97-2003 Workbook
ASKER
Thanks for the help, I think we may have all learned something today.