I have run into an error with an Access Database created in MS-Access 2003. It's known the Calendar Control was deprecated in Access 2010 but unfortunately we need to keep using it. As a temp fix (until we can change to the date picker) we restored the MSCAL.OCX file on all 2010 users.
The issue:
We have a form to print schedules from a date range (using the calendar control). There is some VBA code to check to dates etc to make sure the range is accurate etc.
Everything works fine in 2003 but in 2010 the dates get selected fine on the form, is passed to the report (a print preview) fine as it displays in the footer BUT the query ignores the date range and prints ALL records (not just the records in the date range).
Is there any way I can step into Print Preview button when clicked to see what's being passed?
Any other ideas?
The issue with the filter not being applied to the report is a known Microsoft issue with certain set ups of Windows 7 and Access 2010. The hotfix found here: http://support.microsoft.com/kb/2596496 solved my problem.
I run Windows 7 64 bit and Office 2010 32 bit, when downloading the hotfix I selected the "x86" platform as that's the 32 bit. If you are using Office 2010 64 bit you should download the "x64" platform.
To find out your office version, open any office product, click File Tab, click Help and it will be on the right under "About Microsoft ".
The only way you can really do that is if your report/query is running some VBA code and put a Stop on the the VBA.
If your query is referencing the fields directly (IMNSHO a bad practice, but I'll work with what we've got) you could change them so they instead reference a VBA function that returns the results of those fields instead. Then you know what it is getting for sure.
There is one more trick that surely worked out for me as a solution, before I came across the accepted answer about hotfix on this thread. Also, because, the hotfix link leads to a valid thread, but there are not downloadable files.
The workaround:
Make a copy of the report file. Use that name in VBA under DoCmd call. Strange how it works, though. Such is the nature of bugs, I guess.
Related
In order to create an indipendent runtime file.accdr out of a file.accdb, I've downloaded AccessDeveloperExtensions.exe and AccessRuntime.exe and installed them.
Update:
See article Here is the Google Translater .
Update end.
Opening Access 2007 I could create the install package for creating the file.accdr out of the file.accdb.
The problem I get is that an important function does not work anymore. It's the export of a report, wherelse the export of a table still works.
Opening Access I get the following message:
you don't have a source code control program (such as Microsoft Visual Source Safe) installed on
your machine. The source code control commands are therefore not available
I click on OK and Access opens my db.
My db is based on a table, a form, a report and a query. Exporting the report worked in the past, but doesn't work anymore. The message shown is the following:
Impossible to complete output operation. Assure that there are no syntax errors. If the syntax is
correct, reinstall Microsoft Office Accept...
(I've translated the text from Italian).
Now is there another, easier way from reinstalling the hole thing? Because after reinstalling Access I will also have the need of creating databases.accdr and so I have reinstall runtime.exe and DeveloperExtensions again, what would result in the same problems I had before.
Somebody could help?
I have a device operated via Excel through com ports with MSComm32. Some macro linked to buttons on Excel forms used to make this device work properly. Up to these last days when it suddenly stopped working.
After some investigations, it seems there are some security considerations applied within Excel. The Excel file used up to now does not work anymore if Excel is runs as a standard user. An error message indicates the control cannot be created when trying to enter the creation mode, for example. But, if Excel is run as Administrator, then everything works fine.
Is there an easy way to fix this? For example granting access rights to standard user for the module MSComm32 OCX?
Thanks!
Our office is having a very strange issue with Access 2007.
Long story short - over the past few weeks, half the computers were upgraded to Windows 10, and all of them were upgraded to Office 2013 - except for Access, which we kept at 2007 to keep legacy databases working a little while longer.
All the computers in the office are working perfectly fine under this setup.
Two of them, however, are not displaying some of the Access reports properly. Fields that are not directly linked to a table field and generated on the fly (for example, ControlSource property of the text field something like '=[ThisField] + " and " + [ThatField]') do not show up, and instead display "#Name?" as if it can't connect to the data. However, on the exact same report, there will be fields with the control source directly linked to a field (for example, "MyField" in the query in the report's record source) that will work just fine!
Only two computers in our office are having this problem; the rest display all fields as expected.
Does anyone have any idea why this would be happening? Is it some weird side effect of having Office 2013 and Access 2007 side by side? We do not have Access 2013 installed. It might be worth mentioning that these two computers were purchased around the same time; however, so were two others that are working fine, one of which is on Windows 10 and the other on 7.
Any thoughts or suggestions would be appreciated. Thanks!
I have an accdb database that is used by multiple individuals and stored on a network share. When opened in Acccess 2007 the following message appears:
Cannot open database "\\databasepath\filename.accdb". It may not be a database that your application recognizes or the file may be corrupt
Access 2010 opens the database with no problems.
What is the most common cause of this issue? I searched for database repair tools and can't find any Microsoft tools for accdb files (JetCompact didn't do it). I ran a compact and repair via Access 2010, did a save as locally and then copied it over to the share - no effect.
Other than magically upgrading all my users to Access 2010 (which won't happen) I'm in the dark here.
You may have some features you're using in 2010 that aren't supported in 2007.
Look here for more info.
Most likely someone opened it in 2010, edited your report and saved the change. This will break 2007 every time. 2010 is NOT backwards compatible with 2007
I would make a back-up, make another back-up and then first try importing all but the tables that contain attachments into a new database.
you can also check this: https://dba.stackexchange.com/questions/71906/ms-access-mdb-ldb-database-corrupted
I am designing a shared add-in using VB.Net 2008 and VSTO that has to fire up when any MS Office App is started. It has to work for both 2002, 2003 and 2007 applications. I have managed to put together a working add-in that pops up a test message stating the version of Office and the Application name and tested this across all the apps ok.
The next part of the solution is to code the application specific code that needs to run for document auditing and corporate protective marking as well as, for example; in Excel checking that all the Add-Ins are linked to the Network Add-Ins folder.
My approach from now was going to be to late bind against the application object and set one of my typed (e.g. Excel) application object references which exist in the code to this object.
I'm still relativly new to VSTO so if I am doing something odd please can you let me know! :)
Ta.
I have completed this project and did it the way I specified using late bindig. It works lieka dream for all office apps both XP and 2007. :) I feel like I am announcing this to myself though as I didn't recieve a single answer or comment. Maybe you should have sexed up the title a bit Mas. Yeah maybe I should.