I have developed a VBA/excel program that scans an excel file or a pdf file to extract relevant data and save to a seperate sorted sheet.
The vba/excel program runs fine on my machine but on my coworkers computers it only runs one of the files and then throws an error when trying to run a second file unless the vba/excel program is closed and then reopened.
I thought this could have something to do with the connections related to the queries not being cleared, but after attempting to add code to clear the connections as well my code resorted back to the original problem I was having... VBA Method 'SaveAs' of Object '_Workbook' faild, but only on one computer
What is going on here? Thanks in advance for any ideas
Related
I have to call the below line to save my workbook from another file:
Application.ActiveWorkbook.Save
For the needs of my project, this code needs to be and run in a different file than the one I have open and active.
When this code runs from another workbook, the file that I have it open and actived calls the SaveAsUI to save the file again, even if he was already saved.
Afther run of the code above, the original workbook is losted. I cannot save anymor the active workbook, manually or by macros, and I don't want to save as my original file. Several errors occur, such as:
random filename in the SaveAsUI
Unespected Error, AutoRecover Disabled
Share Rule Violation (PT/BR)
Sorry, I cannot catch this erro in english. Here its translation:
"Your changes could not be saved in 'File' due to a sharing violation. Try saving to another file."
I noticed that this error started after I enabled auto-save for the first time*. I don't know if it is something related to the cloud and Excel gets lost when saving. Also, testing saving the original file outside the network the problem did not appear
I haven't found anything like it on the internet and it has never happened before either.
PS: The workbook with I have enabled AutoSave has nothing to do with those that are giving error. That was a workbook without macros for a much simpler project.
I was able to find what was causing the problem. I initially thought it was the VBA macro part and the "ActiveWorkbook.save" command, but in the end the problem was much deeper.
It turns out that in the same macro that contained the save command there was a call to another function that updated the queries.
the error would stop when going into PowerQuery Editor, going into the spreadsheet query that would later give the share violation error, and in the steps remove the action of promoting the headers.
I have no idea why this is the error. But I tried several other ways in several other places (like every tip in this link1, or this link2, or this link3), the only way that resulted in the solution was this above (that I don't find in any place).
But the promotion of the headers is necessary, so to continue without giving problems I needed to go into the advanced editor and change the second parameter of the line below from "null" to "true" (which is basically to promote headers at the query stage).
let
Source = Excel.Workbook(File.Contents(FilePath), true, true),
With this, everthing now is working fine.
I found a way to retrieve GPS information from the EXIF at https://www.everythingaccess.com/tutorials.asp?ID=Extracting-GPS-data-from-JPEG-files.
You can download the original Access files from https://www.everythingaccess.com/downloads/GPSExifReader.zip
I imported these VBA for Access Class Modules into Excel. I can retrieve all the GPS information EXCEPT the Decimal GPS Longitude.
As I understand this, the coder (Wayne Phillips) is executing code in the machine's memory to create a virtual COM object from the images, thus exposing the EXIF properties.
Everything runs, except the Call VCOMObject.AssignVar(GPSLongitudeDecimal, VCOMObject.GPSLongitudeDecimal) which is in the Property Get GPSLongitudeDecimal() As Variant procedure.
It crashes my Excel 2013 then restarts it. Tried commenting out the offending Call and works on every Property Get procedure. It's just the Longitude one that crashes without any apparent error being raised.
Thought it might be something weird on that longitude exif parameter so I tried with different jpegs, and with different jpegs from different cameras and the same thing happens.
Since this is an intricate piece of Class Modules voodoo, I'm providing a link to my Excel file (https://yiqyyh.s.cld.pt) just click "Download" on the left hand side of the webpage. The Rar file also has three test images with GPS information on their EXIF.
The easier way to test is by running the UserForm1 UserForm and clicking CommanButton1. This will open a browse window to choose an image. If the textbox gets populated, then nothing bad happened, but if it crashes that's my problem.
EDIT: I tried another machine and Excel 2013 crashed.
EDIT2: The other machine is in my work network. I tried running this on my home PC, also running Excel 2013, and IT WORKED. I need to run this at work.
I had the exact same problem as yours:
On 32bit versions of Office, the GPSExifReader worked fine. On 64bit versions, it froze when retrieving the LongitudeDecimal property (latitude and everything else worked fine).
I solved my problem by using another of Wayne Phillips' excellent tools & tutorials. The VBA modules downloadable from that link drag effortlessly into Excel and the tutorial makes it easy to write a macro that returns latitude and longitude.
Hi everyone,
I'am using HP UFT for testing.
I get data from an Excel file and also write data to the same Excel file.
My issue is that when i write data to the Excel file, I can't use it until the test is closed and UFT stops running (UFT won't read it, it's still blank to it).
I need a way to update UFT "view" of the Excel while running, i can't just close and open again the Excel file while test is still running.
Language used: VBScript
Can you help me?
Thank you all
You should use the UFT DataTable. The DataTable utility object gives you ways to import the Excel File programmatically at the beginning of the Test, write the files to there and when it ends, dump it back to a file. As a Bonus, you would also be able to see the DataTable content in the RunReports at the end(under the Data Tab)
Do not forget that everything you do on the DataTable while running the test is written into the memory only. In case the test cannot reach the end where you persist it again, all is lost. You can try error handling with On Error Resume Next, Recovery Scenarios or Class_Terminate based destructors (Create and instantiate a Dummy class, and if the test crashes and stops the Class_terminate will automatically be called where you can do cleanup activities.
I have an Excel Add-in (with a Userform) which connects to an Access database (using DAO) to perform various functions. I've been using this combo for over a decade. Neither the code in Excel nor the database have been changed recently. Just last week, a user reported that one of their functions was taking much longer than usual, so I looked into it. It ended up that the function itself ran just fine, but when the code was cleaning up and ran db.Close it hung up. It doesn't produce an error, it still eventually succeeds, but it takes around a minute to close the db and move on.
I'll go through all of the symptoms and attempted solutions to see if anyone else has any ideas because I'm at a loss.
This only happens when you run db.Execute. I can open the database and close it right away and it closes just fine. If I open it, run a SELECT query to populate a recordset, then close it, it also closes just fine. But if I open it and run a single UPDATE/SELECT INTO/INSERT/ALTER/DROP statement, the Close method will take a minute to run.
My first thought was to compact the db. I cleared out several unused, old tables and compact/repaired, but this did nothing. Same problem.
My next attempt was to recreate the db. I made a brand new TEST db, imported all of the tables from the old one, pointed my Excel Add-in at the new db and did the same tests. Same results.
My next attempt was to try moving it to a local drive (it's on a network share). This slightly reduced the hang at Close, but it's still there. Not that it matters, because this db has to be hosted on a network share.
My next attempt was to delete a bunch of tables from my TEST database. I cleared out about half of them and the hang at Close was reduced a good deal. Clearing out even more reduced it even more. Deleting all but one table eliminated it. So now I know my problem has to do with the size of the db, but why? It maxed out at 500MB after the compact, which isn't that large. It's been running just fine for years. Why all of a sudden would the size/number of tables be such a huge issue? I obviously can't delete all of the tables in the production database just to solve an issue with Closing the connection.
As I mentioned, this code has been around a long time and the prod db was actually in Access 2000 format (mdb), so my next attempt was to change the format. I tried importing it all into both an Access 2003 format (mdb) and the latest Access 2016 format (accdb). The results were the same.
On a lark, I figured I'd trying hitting the db from somewhere other than the Add-in (on the off chance that the problem was in my Excel file). I copied and pasted my test code into a Word 2016 module... and it ran just fine.
That's odd.
So then I tried a brand new Excel file. Also ran just fine.
So I go back to my Add-in and try the code pasted into a Module.
Again, runs fine.
??
So I open the Userform and run my test code again. Hangs up.
??????
I create a brand new Excel file, make an empty Userform, paste my test code in the form's Initialize event.... hangs up.
I immediately run that same code in a Module afterwards... still hangs up. Even though a minute ago it ran just fine in a module in a different file.
But if I close the file, open a new one, paste in the code WITHOUT opening the Userform, and run it, it works fine. Creating/opening a userform will cause all subsequent attempts to run the code to hang.
So here's the Cliff's Notes version:
Excel 2016 DAO connection to large-ish Access database hangs on db.Close under the following circumstances:
1) The db is large (deleting most of the tables helps but obviously isn't a solution).
2) You have opened any Userform at any time during your Excel session. All attempts during OR after the opening of the form, no matter where the code is run from, will hang. Running the code before opening a Userform does not hang.
These results are duplicated on multiple Windows 7 machines, all with what appear to be the latest updates to Office.
EDIT: I was able to try this out on a remote machine running Excel 2013 and there is no hang (using the original Add-in/db that first exhibited the problem). However, that machine is in our data center which is the same place that the network shares are located, so there are at least two possible reasons why it doesn't hang: 1) Different version of Excel and 2) Different/faster network connection.
If you're wondering why I'm using DAO instead of ADO, it's because of what these functions do (lots of stuff with looping through Tabledefs to modify indexes and even create/modify the table Description, which can't be accessed via ADO. If it weren't for all that, I'd just switch to ADO and be done with it. It's possible that I might be able to come up with ADO alternatives/work-arounds for everything that it's currently doing, but I'd rather not rewrite this entire Add-in if I can help it.
I'm at a complete loss on this one, so if anyone has any ideas, I'm all ears.
I have a vbs script which writes to an Excel spreadsheet. To be able to save the spreadsheet I need to ensure that it is not already open.
Can someone suggest the best way to do this?
Some research:
I tried to create a Word Tasks objects to show me all running processes, but on Windows 7 it only tells me whether Excel is running or not.
Creating an Excel.Application object does not give me access to all running instances of Excel.
I thought about opening the spreadsheet for writing but the only way I can think of doing this is with the File System Object OpenTextFile method which does not seem to be the correct approach as the Excel file is a binary.
Any other ideas?
Since the Excel.Application object doesn't give you access to all instances of Excel, what about using a simple error trap? ie. if it is unable to save the file, throw a warning message, save as another file name, etc.