I have an office 365\ excel app using vba\ ado\ custom ui ribbon\ xml.
I have been seeing corruption from time to time but cant pinpoint the cause-- and only become aware of it with some testing of the saved workbook.
I am going to accept that corruption occurs for whatever reason-- and perhaps that would be another thread.
My question is-- are there resources\ utilities out there that would allow one to determine if a workbook is corrupted-- versus a full regression test with every set of changes (save).
Related
We moved to Sharepoint Online (SPO) this year and are collaborating heavily in Excel365. The experience is something of a disaster and I am hoping that I might get some responses here about "best practice" or peoples' experiences in that environment.
Observation #1:
All Excel's now open with AutoSaveOn=True. This is a total disaster because people often open Office files to simply take a look. Early users were horrified when they realized they had accidentally changed an archive file. We addressed this issue by setting AutoSaveOn=False in Auto_open.
(The AutoSaveOn=True experience requires a complete rethink of accustomed operating patterns. The established pattern when changing a file is: 1) open the original; 2) make changes; 3) save under a new name. With AutoSaveOn=true, you must: 1) make a copy of the file in the file manager; 2) open the copied file; 3) make changes. We have not managed to retrain our user base.)
We now get a different issue. In a network environment where 5 users have an Excel open purely for reference, the 6th user who is editing that file often has to fight against Office/SPO to somehow get it saved. There exists a concept of a "file lock" and someone has it. Who is unclear, and releasing it seems next to impossible. Opening an Office file "read-only" on purpose does not seem to be a concept Microsoft recognizes.
Observation #2:
All our production Excels are XLMs, not least because of the Auto_Open above. That is, working Online is not an option. (Which may be just as well because the online experience does not compare for the Excel pro.) All our users therefore synchronize relevant SPO archives to their OneDrive (OD). This should be a good thing anyway, since we are also nomadic folk, often working from the road when there is no internet. SHOULD NOT be a problem, right?
Right ... Turns out that Excel surreptitiously replaces links to other Excels on the OD with links to SPO such that when you hit the road, Excel will just hang up trying to access stuff on an unavailable Internet/SPO :( The user is forced to repoint all links manually to his OD to make it work.
Except it won't - because the Auto_Open now fails. Turns out, AutoSaveOn is not a valid property in the absence of a network connection. It seems that there are two code bases of Excel. One that is invoked with a network present, the other when there is none.
Observation #3:
When the user has somehow survived the horrific offline experience and returns to a network, the spreadsheet links fail again. Excel now throws a completely incomprehensible hissy-fit, complaining that none of the OD files exist, even though they are patently there. The only way I know to cure this issue is by going thru all links again and repointing them to the identical paths. (Behind the scenes, Excel of course uses this dialog to replace links to OD with links to SPO.)
Conclusion:
It seems that the modern Excel really wants to work in AutoSave mode but Microsoft doesn't really manage the experience. There is also no transparent switching possible between working offline and working online. All of this appears to be owed to two different code bases - online and offline - trading under the same name "Excel". We do not really require the online experience. It would be perfectly adequate for our purposes to work with the offline code on OD only, and OD can update SPO when a network is present.
Question: Does anyone know how to fool Excel into using the offline code base even in the presence of a network connection?
Any other experiences or pointers?
I have a requirement to update an .xlsx file that is simultaneously open in MS Excel.
This should work so that the formulas are re-calculated every time value in updated while user can see the updates happening in real time in Ms Excel.
Tried with OpenXLSX, but didn't work as I want it to (which was somewhat expected).
I done some research(on SO as well) and the term Interop keeps popping up, though not in context of c++ but c#.
I know it is not impossible, as I have seen it in action.
Is there an existing library that can do this operation using c++?
If not, how should I move forward to achieve the said goal?
It would really help even if you could point me in the right direction.
Appreciate any help.
I'm currently writing my master dissertation about version control in Ms Excel and would love to understand the problem more thoroughly. Does anyone face the problem and would be willing to discuss this in a 10min zoom call? Will hopefully be able to provide the solution in 2 months time.
t.muller#lse.ac.uk
Problem description:
If I'm working on a spreadsheet and need input from my co-workers on the same spreadsheet, I'd start to send the sheet around (probably via Email if we worked on excel offline). Unfortunately, we tend to quickly lose an overview of the different versions in the chain, and it sometimes even happens that some of us are mistakenly working on an old version. As soon as we managed to gather the input from everyone, we struggle to get to the root of newly introduced bugs and understand and approve all changes made.
I have been programming small to medium macros in VBA for two years now to improve efficiency within my organization. Excel 2010, saving workbooks as .xlsm.
After 3 days into my current project, I started getting an Unspecified Error, followed by a Catastrophic Error. I can't save, I can't do anything except close the window, when about 5-15 Catastrophic Errors pop up, file is not saved, and I have to pick up where I last saved or autosave kicked in. After it happens once, it happens every 5-30 min until I revert to an older save. Then I get a couple days before it starts happening again. It's ridiculous because this project should take about 1/3 the time it is taking me because of this error. I am only posting now because I can't for the life of me figure out why this error is occurring. I have built much bigger programs before that behave very similarly, but this one keeps crashing.
Some differences from my usual techniques that I have noticed and tried to leverage to pinpoint the problem:
-I am referencing the name of the workbook from a function so that if someone runs this macro from another sheet, it will always do work in the correct sheet
-I am using multiselect listboxes that point to defined tables within excel worksheets. These tables are refreshed often with OLEDB connections and then the listbox is reset via .rowsource property.
-I am using different frames to show/hide a group of controls, all overlapping on the same form (in other macros I've done, different forms exist for different functions)
I don't know if/how any of these things would cause an unspecified/catastrophic error. I am happy to post some code, but I wouldn't know where to start. There's a lot of it.
One more thing, it seems to get hung up with a "Could not set the RowSource property. Unspecified Error" with code -2147467259 at first, and then start crashing a lot after that happens once. I'm not doing anything particularly different when setting the RowSource property.
Any help or ideas would be much appreciated. I have searched a bunch so far with no avail, feeling a bit like http://xkcd.com/979/
We have a lot of reports that are generated via VBA & Excel. Only a small percentage of the reports are actual calculations - the majority of the work is sql calls and formatting/writing of cells. The longest of which takes several hours, the majority takes around 20-30 mins each.
The VBA/Excel code plugs into a dll that the VB6 desktop apps use - it's here that all the sql calls are made. While I am sure that there is room for improvement here, it's not this that concerns me - the desktop apps are fairly snappy.
Two VBA functions are used in abundance: These are called GetRange and SetupCell and they nearly always appear together. The GetRange function is a wrapper for the Excel.Range object. It takes a sheet, and 4 values for the extents of the range. Its main use is to pick the cell for editing. There doesn't appear to be much chance of optmising it, but is it the best way?
Its partner is SetupCell. This takes a Excel.Range object, text and a dozen parameters about the cell (font, borders, etc). Most of these parameters are optional booleans but again, it seems very wasteful. Some of these can be set posthumously but some are dependant on the values contained in the cell.
There's quite a lot of code contained in these functions, mainly if statements and work won't appreciate me posting it.
I guess I've got two questions: Is there a better way and what is it and is there are free profiler that I can use to see if the bulk of the time is here or in the dll?
several hours is ridiculous for a report.
If the problem is VBA buy "Professional Excel Development" (stephen Bullen, Rob Bovey et al): this has a free VBA profiler called PerfMon.
If the problem is Excel Calculation see http://msdn.microsoft.com/en-us/library/aa730921.aspx?ppud=4
But I would guess that the problem is the high overhead associated with referencing things cell-by-cell: you should always work in large blocks of cells at a time.
Have you thought about using an actual reporting solution? What's your backend db? If you are using MSSQL 2000 or higher there is a fairly decent reporting solution you can use free of charge. SQL Server Reporting Services.
It sounds as if the reports are spending most of their time formatting cells. This could be why the reports seem so slow and the desktop app doesn't.
Alternatively, if you know the formatting before hand and it is fairly static, you could pre-format the sheets to cut down on some of the work.
I will throw this in there as well. Most reporting solutions will allow for conditional formatting and such, but since they are designed to work as such performance will be much better than having Excel do it.
This isn't a profiler recommendation, but it is a suggestion for speeding up Excel macros that are spending their time updating the screen. I've had excellent results by turning off screen updating while the macro is running: set Application.ScreenUpdating= False, and also using a number of other similar settings. Just be sure to turn them back on again when the macro finishes :P
It's not free but you can profile with this. I suspect the demo will be adequate to your needs: http://www.aivosto.com/vbwatch.html
It sounds like the VBA code (or the VB code that's writing to the sheets) is doing so line by line, this can take ages, and is poor design. Write to Excel as a variant in one go. Format the sheet after the data is all imported.
Thanks
Ross