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?
LVL 13
TorrwinAsked:
Who is Participating?
 
TorrwinConnect With a Mentor Author Commented:
Here's what fixed it, though I have no idea why their machines were set the other way to start with...

1)  Open a blank workbook
2)  Go to "File" -> "Options"
3)  Select “Save” from the left navigation menu
4)  Select “Excel Workbook" from the "Save files in this format" drop-down list
5)  Click "OK" to save the changes
0
 
MajorBigDealCommented:
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?
0
 
TorrwinAuthor Commented:
That was a thought I had too, but those users have 4GB.  Shouldn't that be enough to handle a spreadsheet?
0
Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

 
KorbusCommented:
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.
0
 
TorrwinAuthor Commented:
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?
0
 
MajorBigDealCommented:
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?
0
 
TorrwinAuthor Commented:
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.
0
 
KorbusCommented:
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?
0
 
TorrwinAuthor Commented:
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.
0
 
MajorBigDealCommented:
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.
0
 
KorbusCommented:
Wow, good catch, I never would have thought of that.  What format WAS it using by default?
0
 
TorrwinAuthor Commented:
Excel 97-2003 Workbook
0
 
TorrwinAuthor Commented:
Thanks for the help, I think we may have all learned something today.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.