I have a legacy app I am currently supporting that is having problems when people copy large quantities of data from a datasheet view.
The App is built in MS Access and the amount of rows being copied can get pretty large (sometimes in the thousands).
The funny thing about it is, you can paste the data out, but then Access keeps "rendering" the data into different formats and becomes CPU bound for LONG periods of time.
The Status message beside the progress bar at the bottom right of the MS Access Window is
Rendering Data to format: Biff5
Biff5 is a "Binary Interchange File Format (BIFF) version 5" According to Source
The app code doesn't use BIFF5 anywhere so I don't think this is an app problem.
I cannot find any data on this error anywhere on the web so I thought it would be a good question for stackoverflow.
So, can anyone help please?
Instead of trying to copy-paste, can't you just export the query to Excel?
I am not sure what the problem is but sometimes you can run into some very quirky bugs with Access. Have you tried running this on different machines? Different OS's? Would it be possible to paste the data into Excel and then import into Access using import functionality? Can you import the data directly instead of pasting it?
Try copy-paste operation through VBA:
Once user has selected data to copy, you can execute the code below when click on a button in the form, and then do a pastespecial in excel:
--- Data selected by user ---
RunCommand acCmdCopy
Dim xlApp As Object
Set xlApp = CreateObject(Class:="Excel.Application")
'New Excel Workbook
Dim xlWbook As Object 'Excel.Workbook
Set xlWbook = xlApp.Workbooks.Add
'Paste in excel
xlWSheet.Range("A1").Select
xlWSheet.PasteSpecial Link:=False, DisplayAsIcon:=False, Format:="Biff5"
We are all on the same OS here for this, I am investigating the possibility that some update sent out in the last maintenance window has caused this, as it wasn't a problem before this and there have been no new releases of the software in that time period.
Tried in on lot's of machines, same issue on them all.
The problem is actually with copying from a datasheet view in Access and pasting to Excel, not the other way around strangely.
Here is the use case
Access --> "Copy from datasheet"(Normal Ctrl+C) --> "paste into Excel" (Normal Ctrl+V)
(this works fine!)
When you then go back to Access to continue working, it is CPU bound doing the "Rendering Data to format: " thing, I mentioned above.
I'm stumped to be honest, it's all a bit strange.
Related
I am using Access 2007 on a PC running Windows Vista.
The Access database with VBA code in many modules works as expected. However, one module acts differently after I have exited the database and re-entered. As soon as I re-enter, I can select View Code and Save without changing any code and the program goes back to working the way I expected. Any ideas?
Details:
The Access module with the inconsistency opens Word 2007 and creates a new document from a template (.dotx) file using bookmarks to merge Access data into the document. This works as designed without a problem and works every time. Once the document is created, the vba code calls the Word window to front. This does not happen unless I select View Code and Save. I do not have to modify any code, just select Save. Then it works as expected until I close the database. When I next open the database and select the button that creates the Word document, the document is not brought to front but remains behind the Access window. If I select View Code and Save, the subsequent documents created during that session come to front as desired. This is consistent and repeatable.
I am not sure about why this is occurring, but a quick fix that I thought might work would be to programmatically save the module when you load your DB.
docmd.save acmodule, "module name"
Hope this works!
I followed the suggestion by Cody Gray about halfway down the page in this thread but I'm having no luck.
Unless I'm missing something, this is supposed to allow me to navigate from Access, using the Windows API Dialog Box, to the relevant folder and open a file, no? I'm trying to open a Word doc which has a Mail Merge coming back to the same Access Db. I needed the dialog because there are multiple files that may be selected at different times.
I added all the suggested code and while the process runs without error, when I get to the final step, the selected file doesn't open. Nothing happens.
I realize this is not much help without an error message. Any thoughts nonetheless?
As I understand the situation, you have code which uses a string variable named strFileToOpen to hold the path to a Ms Word document. And now you want to open that file in Word.
You can use the FollowHyperlink method.
Application.FollowHyperlink strFileToOpen
Look at the Access help topic for that method. It offers other options you may wish to use.
Also I suggest you look at the help topic for FileDialog Object. It is simpler than the Windows APi method in the code you linked.
Ok, I'm creating a Word document (based on a template) from MS Access and updating several charts by using the OLEFormat object. Once I .Activate the object, which creates a new instance of Excel, and make my edits, I close that instance of Excel with:
wdChart.ChartData.Workbook.Application.Quit
This works fine if there are no other instances of Excel running. But, if there is an open instance of Excel when the OLEFormat.Activate happens, it doesn't create a new instance of Excel, but opens the chart spreadsheet in the same instance of Excel that is open. So when I execute the .Application.Quit command, it closes ALL open workbooks in that instance and prompts me to save the workbook. At this point, I get a Word message that says:
To insert a chart, you must first close any open dialog boxes or
cancel editing mode in Microsoft Excel
The my code fails with a:
Method 'Activate' of object 'ChartData' failed
I think these errors have to do with the fact that my code is sequentially editing several charts. When the Word dialog pops up, my code is still trying to run or something.
I think what would solve all of this is if there is a way to force the OLEFormat.Activate to open it's own instance of Excel. Is this possible?
You need to check to see if there are more than 1 workbooks open. If so, then close the chart workbook, otherwise, quit the application.
If wdChart.ChartData.Workbook.Application.Workbooks.Count > 1 Then
wdChart.ChartData.Workbook.Close saveChanges:=False
Else
wdChart.ChartData.Workbook.Application.Quit
End If
I had a similar issue with this and with "AddChart", for some reason in Office 2010(not 2013 or 2016) sometimes when accessing multiple charts in a row the excel windows doesn't close before another one opens. This causes the error that #MultiGuy experienced.
I my case I just added a small wait time in front of my "Activate" and "AddChart" calls and it seems to have resolved the issue:
Excel.Application.Wait Now + TimeValue("0:00:01")
Long term I should probably write some sort of function that waits until the associated excel window has closed, but for now I think this much more brittle approach will work in most scenario's.
MS Access 2010, Win 7 on a regular formI didn't intentionally place any ActiveX or OLE things.. not even sure what they are. But anyways, whenever I put something in the code of a particular form, it says "The Expression XXXXX you entered as the event property setting produced the following error: A problem occured while MyDB was communicating with the OLE server or Active X Control
Huh? No matter what I put in the form's code, this happens. I had an empty Form_Current() ONLY which still tripped this. There's a lot of formatting and work into the form, I'd rather not scrap it.. If I leave the code window completely empty (only Option Compare Database), it does not trip the error; however then my form is useless.
I've seen things about this being a language issue, but my other forms (running the same code techniques and most of the same code) are fine and it's an english Access with an english language PC. Ideas?
Code setting off the error:
Private Sub Form_Current()
End Sub
Seriously.
I faced the same problem and I tried many things, the only (and fastest) solution that worked is to do the following:
1) Close the form that is causing the error.
2) Rename this form.
3) Duplicate it: Copy, then Paste, you will be prompted to set a name for the new form. Give it the original name.
4) Delete the original form that was causing the error.
5) Open the pasted form and it will work OK.
This solution worked fine with my database...
Regards...
Check for missing references. Make a back-up, decompile, compact & repair and if that does not work, copy everything to a new db ( http://www.granite.ab.ca/access/corruptmdbs.htm ) You may have to skip copying the problem form. Sometimes it is worth creating a new form, selecting all the controls from the old form and pasting into the new form.
you can change the language setting to have a try, the steps are as follow:
1、Open window command ,run "intl.cpl"
2、choose the Administrative item ,change the system locale settings.
Hope that can help you.
I have run into this problem many times. The error statement is horrible as it provides basically no useful information. I have found that Abu Hassan's solution typically works best (duplicate the form and delete the original) but that did not work for me on one occasion, where I had to delete an import statement that I had recently added:
imports system.collections
Once I deleted that import statement everything worked again. So if duplicating the form doesn't work then try undoing something you recently did. It could be this import statement or one similar to it.
Very strange error, that sometimes occurs in my databases too.
It seems to go wrong mostly on UNBOUND FORMS (unbound forms have no RECORDSOURCE).
What I have done recently is :
temporarily define "some" table (e.g. a config table with just one record) as the RecordSource,
compile the program (Note that this usually goes OK, even before the fix!)
Save the form.
Open the form. This should work fine now!
Delete the RecordSource, recompile and save again.
Most of the time, my forms work fine again after that.
as my experience some of errors because you use your local language in VBA statement
so you must adjust your local language as language of system from control banal >> language or region>>administrative>>change system local then select your local languages
or find the word was not English in vba and retype it by English
According to http://support.microsoft.com/kb/288902/en-us
You can attach to a specific instance
if you know the name of an open
document in that instance. For
example, if an instance of Excel is
running with an open workbook named
Book2, the following code attaches
successfully to that instance even if
it is not the earliest instance that
was launched:
Set xlApp = GetObject("Book2").Application
Th example works for Excel, mainly because the "Document Name" is nearly the same as the filename. I need to get this to work for Access.
I have users running multiple instances of different Access Applications (.ADP) and I need to get one with a specific name. I do NOT know the complete filepath, otherwise I could do a simple
Set app = GetObject("c:\my\app\myapp.adp", "Access.Application")
Currently, I go with calling
Set app = GetObject(, "Access.Application")
and check the returned Application.Name. If it's good, I use it to call some functions on it, if not it fails. I have heard about the Running Objects Table, but since I have to get the object inside a VBScript, it's a bit too much API-calls.
Bottom Line:
What is the correct "Document Name" of an Access ADP to use in the GetObject("Document Name") call and what type of object does it return?
Coming back to this question because #phoog posted an answer, it occurs to me that since Access can have only one database open at a time, you'd need to look at each instance of Access and check its CurrentDB.Name. Now, with an ADP, I don't know what you'd check instead, but perhaps it's CurrentProject.Path.
I don't believe any of that actually addresses the original question, which seems to want to find the instance with just the filename, but I don't think that even if that worked it would be a good idea. You could easily have independent Access apps that return the same application name and filename but are stored in different locations in the file system.
You probably want to read this: http://support.microsoft.com/kb/147816
Unfortunately, it looks like "Document Name" has to be the mdb file, so if you don't know the file path, you're not going to be able to use "Document Name".
In addition to the fact that Excel can have multiple documents per instance, Excel also prevents you from opening two documents with the same name, even if they are in different folders and you are opening them in different instances of Excel.
On the other hand (to address David-W-Fenton's comment), Access does allow you to open multiple instances of the same database (not to mention different databases with the same name), as long as you don't open any instance in exclusive mode.
This is further evidence that the way Excel registers its documents in the ROT is very different from the way Access does so.