Hello everyone and greetings from Germany!
After searching for quite some time I am at my wits' end and I hope someone can help me.
I try to describe my problem as clear and briefly as possible:
I am building a MS Excel 2010 Workbook that includes several (90+) external connections to SharePoint 2013 Lists & Libraries.
These connections were created by SharePoint's integrated "Export to Excel" function (in the List/Library-Ribbon) and the connection-files were then exported to another SP farm.
(The first "source"-SP-Farm is from the customer, the second is our own intranet)
I have to refresh these connections once per day via an automated macro.
A timer-job will open the workbook at night and execute the "RefreshAllConnections"-macro,
that does a little bit more than just refreshing (such as writing the refresh date and time).
So no user is present when this happens.
And this is where my problem is:
From time to time some of those connections cannot be refreshed.
Excel displays an alert saying (translated from german):
"the following data range could not be updated: owssvr (...)
Do you wish to continue the update?
(OK) / (Cancel)
What I found out so far:
1) It's always the Library that is the problem
2) It's rather random which Library won't update and when
3) The problem fixes itself after some time (that's why I'm guessing this has something to do with the library being used/modified by someone else)
4) While a library is refusing to update, using "Export to Excel" function again will prompt an error once the new worksheet is created and the data is supposed to be filled in
Now here are the odds:
1) The alert always uses the "old/original" connection name that was already changed by me.
2) When I press OK the macro just continues in the next line, no error is thrown whatsoever
3) If I press cancel an Error 1004 occurs (which I can at least catch, so that would be okay).
And here are the probs:
Since this is happening automatically at night, there is no user sitting near by to answer these alerts. So:
1) The macro must automatically answer these alerts with "Cancel" IF they pop-up (and I have NO idea how to do that!)
2) I disable them via "Application.displayAlerts = false
HOWEVER: this will automatically answer them with the default answer, which is "OK".
This however is not throwing an error I could catch, so my macro won't now whether the update acutally worked or not.
Well that's about it. Sorry for the long post and thanks for reading.
Hopefully someone of you has an idea.
EDIT:
Could it be that the automatically by SharePoint generated connections are the problem?
(How) can I build them myself?
Well. I solved it myself.
The answer was stupidly simple:
Instead of refreshing the Connection, I now refresh the corresponding QueryTable via "ActiveSheet.ListObjects(1).QueryTable.Refresh"
If the Connection is not responding, an error is thrown that I can now catch properly.
Ugh, finally!
Related
I have 6 computers that a shared VBA Form in excel is pulled up on.
My problem is, is that the document is frequently saved and updated. The people that enter information will save the entry at the same time as another is saving and it causes an error. That error causes it to crash and we need to repull up everything which takes awhile, and hoping it didnt loose the entry.
Is there a way to prevent this from happening altogether? or is there a code that if the save error occurs, a msgbox will pop up and say "This Document was saved at the same time as another" and then maybe a "Try Again" button on it, that will continue saving the entry?
Any help would be awesome! Thank you!
I've created a simple spreadsheet that has 3 worksheets that are utilized in Data Queries & Connections processing. They are accessed in the m code with statements like "Source = Excel.CurrentWorkbook(){[Name="TPCT_Static"]}[Content]")". The results of the processing are ultimately connected to a table in the same workbook. When I execute some simple VBA code (i.e. Selection.ListObject.QueryTable.Refresh BackgroundQuery:=False) to ask for a refresh, all is good -- processing occurs and output table is updated. However, anyone else who uses the spreadsheet and asks for a refresh, via the same macro, gets an error "runtime error 1004 - application defined or object defined error" when it hits the above line of QueryTable.Refresh code.
I've had people run the sheet on their PCs, remote into my PC and try to run it there, and everyone but me gets the error. My mind goes to some kind of permissions issue, but all the data is local in the workbook. There were external SQL queries in the spreadsheet in the past but these were all removed -- really. Everything is now static data held in the workbook.
Any ideas?
Thanks,
Mark
The comment about "Fast Combine" got me thinking. Since most of my work is just for me, I typically set Power Query privacy to "None". Perhaps this was the origin of the issue? So, I reset the level to "Public" and then I started to get an error message when I tried to refresh: "Formula.Firewall: Query 'QueryName' (step 'StepName') references other queries or steps and so may not directly access a data source. Please rebuild this data combination." Resolving this error was clarified by instructions at the following site. "https://www.excelguru.ca/blog/2015/03/11/power-query-errors-please-rebuild-this-data-combination/". It is a very nice write-up. I'm not sure why the privacy level of "None" didn't work for everyone, but after attending to the rebuild, refreshes work for everyone. Thanks to all who read the post, made suggestions and thought about a solution.
Thanks,
Mark
I have a random problem related to OleObjects.
I have developed some code to upgrade a set of user sheets. The routine copies and pastes tabs from one of the sheets, using:
Convert_V1toV2 ThisWorkbook
When I then want to put it into practice, then the code opens the sheet concerned and the same code is called, so it gives something like this:
set wb = Workbooks.Open(...
Convert_V1toV2 wb
In this code, I have to create Forms.OptionButton.1 type ObjectOle. The code works in the first case, and crashes in the second case, with the message:
Error 1004 Unable to get Object Property of OLEObject class
I set up a test to anticipate this crash:
Function oloTest(wb as Workbook)
Dim olo as OleObject
...
Set olo = ws.OleObjects("oTitle_Type_ProductPart")
olo.Activate
...
End Function
The first instruction works, but the second hangs (error 1004), as well as if I ask for olo.Name or other properties. It's the same on two machines.
I looked it up on the Internet. Deleting MSForm.exd does not change the case. All other explanations fall because it works well in one of the two contexts.
By dint of searching, I finished to have oloTest()=True, if the sheet is put in the foreground.... That's nonsense. Now the conversion test passes, but once in a while there is a sheet that returns a strange crash (a compile error: "Only comments can appear after End Sub, etc." then leading to "Error &h80010108 The Object method of OleObject has failed" while my worksheet at that time still has no code at all). This happens when my OleObjects are created and I want to assign a value to them ws.OLEObjects("oComittee_Classification_Stand").Object = True, when I can read them...
This conversion involves hundreds of sheets and it is an operator that will have to apply them. I would therefore like a stable solution. Do you have any ideas?
I had to work on the conversion of another one of my applications for a customer. The amazing fact is that I encountered exactly the same type of problem with sheets containing only Userforms and not a single ActiveX control.
Some of the workbooks I had to convert had crashes very similar to what I described in my initial message as soon as I coded these objects, even though there were less than 10 simple buttons per sheet and nothing else.
This suggests to me that I wasn't necessarily dealing with a crash of the ActiveX, but maybe with a crash of their container, the Shapes, or at least that the Userforms are no more reliable than the ActiveX.
This contradicts Rory's initial answer that I should do without ActiveX.
This is the first point of my answer. The second point that supports the first is that I managed to repair the damage: over 800 sheets were converted on site without this particular crash happening again.
The solution was presented in the problem statement: in tab copy mode the crash did not occur.
The Excel repair (CorruptLoad:= xlRepairFile) didn't work, so I experimented a personal repair using the WorkSheet.Copy command I was using in development mode, and it worked. I won't describe here the drawbacks of this command, that's another subject.
I tell myself that this command must read each element of the source WorkSheet with a requirement, a reliability and an exhaustiveness that the repair does not know: corrupted Shapes objects do not make it crash and moreover are corrected in the destination, whether they are Userforms or ActiveX.
As an aside and without really finding a cause and effect link, I found in both developments that the WorkBooks I had to convert had the KeepChangeHistory property to true. This had given me an absolutely incoherent error message when I created a WorkSheet by code which had put me the chip in my ear. But, if unchecking this property did not fix the problem, there is no indication that it was not the property that triggered it.
I would like to point out that these two developments have been made by generations of non-developers, from the trainee to the user, and that I took them back like so many spaghetti packages to be unraveled, because it had become impossible to make them evolve, this to say that I don't know their history nor what really corrupted them.
I have built an application that opens an Excel Template from Access. Everything was working wonderfully until I introduced linked pictures in my Excel Templates.
The entire application which used to execute in a few seconds now takes close to a minute to do only such simple things as write data from Access to Excel.
The reason for this is that Excel gets stuck in CalculationStatus = Pending probably because I'm using volatile functions for my linked pictures (offset).
Microsoft is aware of this issue and has kindly documented it along with their "resolution" here... which is essentially nothing.
Does anyone else have an idea how to resolve or work around this issue? I have tried changing my template and not using linked pictures but these solutions don't work very well / are cumbersome.
UPDATE:
I have tried the various solutions that were proposed in the comments. None have worked yet. After having eliminated those options I am essentially at the point where I see that as long as the worksheet contains a linked picture, this bug rears its ugly head.
I'll leave the question open in case someone else does have a workaround.
My own solution for the time being is that I'll be writing code to update the relevant cells using VBA.
i am new in ms access. Now i have to finish some modifications in ms access 2003. I am getting this error "you do not have access to the database this time. If you proceed to make changes,you may not be able to save them later". Please help me to solve this problem.
Microsoft has documented the problem, but the sugested solutions were completly unusable in most of my situations. Furthermore the issue occurs even in a split database and it occurrs inconsistently with forms and controls that use code. In my opinion MS got this wrong or at the very least documented incompletly.
Here is my solution:
The problem in many instances traces back to Access thinking the DB is in an exclusive mode, when it should be in a shared mode. Setting the DB to "shared mode" under Options doesn't help, because it will revert back to "exclusive" any time a user turns on the "design view" for any object in the database OR makes code modifications OR if a user presses "save" (CTRL + S)!
In order to prevent the error message from poping up, you need to prevent the users from pressing "save" or switching to "design view" in your DB. I have deleted the save button in the Quick Access Toolbar (so users don't see it) and under Options>Current Database I have unchecked "Allow Full Menus". Additionally you can also uncheck "Enable Layout View" in the same menu.
Possibly the Save function can be disabled alltogether, but I have not yet written code for this. This solution is not fool proof, but it greatly reduced the occurence of the problem in my various split and unsplit DBs.
I was getting this error in ms-access-2010 just the other day. I was working with a method in vb to query the db. I needed to commit my transactions and close the database object after I was done with it at the end of the method. This fixed the problem for me.
This occurs in Access 03 when you are not the only live user present in the .mdw (security) file, if this is a shared database then before making any changes you will need all other users to log out and then to ensure this error doesn't occur again, always open the database in 'exclusive' mode for editing, this is achieved by selecting the little arrow on the open button.
However, you can also have some strange behaviour with .mdw files, if you are genuinely the only user logged in, then I would suggest first logging out, manually deleting the .mdw file if it exists and then going back into the database.
Always open the database in "exclusive mode" when programming and this will never happen.