I am developing an Access application on Access 2019. I have split my project into a frontend and backend. I am trying to deploy the application to a user that is using Access 2016. When linking the backend tables in the frontend file, I run into this error:
The Microsoft Access database engine cannot read the data in Receiving.
The minimum required version to read the data is 16.0.7124.1000.
This only happens for two of my tables however, Customer and Receiving. These are the only 2 tables to use an AutoNumber field with the Field Size set to Long Integer.
Is this an issue with the AutoNumber? Or is the Long Integer field size not supported in Access 2016? Wondering what the best option is for me to link this table to a 2016 version from a 2019 version.
Edit:
Here is the output of the Database Documenter tool for the Receiving table:
This specific error is caused by the Large Number data type, or BigInt.
You can read the documentation on that here
Note that support has been added to Access 2016 in later updates, that's why the minimum required version starts with 16 which corresponds to Access 2016, so just updating Access 2016 might solve your issue.
Else, remove all large number fields.
Note that Large Number and a number set to Long Integer are entirely different things, a long integer is 32-bit long and supported by all versions of Access, a Large Number is 64-bit long and only supported since Q2 2017, and has certain issues when working with it in VBA.
Access tends to sneak in the Large Number datatype when importing from Excel. I strongly recommend you avoid it unless you really need it, both for compatibility reasons, and to make using your tables in VBA a lot easier.
The rule tends to be simple:
You can near always go forward. That includes word, excel, or Access.
In other words?
You have to develop with and use the lowest common version of Access. So, say you can work with Access 2010. Then 2013, 2016 and 2019 users will have no problems.
But, going "back in time" or "back in versions"?
That tends to be a problem.
So, if you still going to have some users of 2016? Then that has to be what you use for development. This issue often applies to Excel or word. You use the v-next great version and some new feature (or new format)? Then previous versions can experience trouble.
Related
I built a db for MS Access 2016 (both front end and back end) and it has grown to be very extensive (130+ queries, 50+ reports, etc...), but I have just stumbled upon a user whose copy of the DB isn't working because of compatibility issues.
I was wondering if there was a setting in the menu that might make the DB think it is running version 2013. This would help me with the present problem of adjusting the current DB to accommodate this user.
The generally accepted solution is to ALWAYS develop with the lowest common version. Access handles and works VERY well when moving forward, but not backwards. After all, a very old computer might not even have windows or a mouse – you can’t expect it to run modern software.
So the general approach is to develop in 2013, or even 2010. The resulting compiled accDE you distribute to each workstation will in near all cases run without issue. So there is no “switch” or some such. If the lowest common version of Access is 2013, then that is the development edition you should work with. Thus users with 2013, or 2016 should not have any issues.
Of course the other tip is to split your database (you clearly done that). And ensure that each workstation receives a copy of the front end (application part). So keep in mind that you don’t want to open + use a single deployed front end with “different” versions of Access. Following the above simple approach should result in a trouble free deployment approach and allow the two versions of Access to work without issues.
edit:
Also, if you have any references to a particular version of outlook, Excel, word etc., then you need to remove those references and adopt late binding.
Using Access 2013, Sharepoint 2010 OnPremise
I have an Access database that uses Sharepoint 2010 for a back end using Linked Tables.
A few months ago there was a request to have a field contain multiple values, and I stupidly implemented that change, not fully understanding all the issues behind that. Initial research lead to it being "ok" for Sharepoint Lists.
Due to the company architecture, this application needs to be accessible on a Kiosk machine that doesn't have access to the Sharepoint site, but still is connected to the internet.
If the computer runs the application while connected to the internet it will hangup/stall when opening because it's trying to resolve the connection of the linked tables or trying authenticate.
But if the computer runs the application while not connected to the internet it will operate as it should in an offline mode. All data is accessible.
Since we can't/don't want to disable the internet of the Kiosk machine the solution was to convert all the Linked Tables to local tables and issue it to the machine that way.
But now a few months later when trying to make the offline mode application we get the following error:
You cannot enter that value because it duplicates an existing value in the multi-valued lookup or attachment field
I think it has to do with that multivalue field, which has turned into a huge headache, but can't be undone for at least a couple more months.
The Offline mode functionality was created long before the multivalue change, unfortunately that part of the application wasn't tested against this changed field.
So I need to know if there's a way I can convert the table, or if there's another way to Force Access 2013 into an offline mode.
Thanks,
Dennis
It has been a good number of years since I did some programming with Classic ASP and Microsoft Access where we used "Microsoft.Jet.Oledb" driver to access and display the data.
I have been asked to do some work with accessing MS Excel data using "Microsoft.Ace.Oledb". I have found this to be part of the "Microsoft Access 2010 Engine Redistributable" download.
I would like to know if "Microsoft.Jet.OleDb" has replaced "Microsoft.Ace.Oledb" driver and are essentially the same or are they completely different things?
Also, do you normally get the "Microsoft.Ace.Oledb" driver when you buy MS Access 2010?
It's mainly a matter of history, effectively ACE has superceded JET:
Wikipedia answers your question in great detail.
The most relevant sections are:
With version 2007 onwards, Access includes an Office-specific version
of Jet, initially called the Office Access Connectivity Engine (ACE),
but which is now called the Access Database Engine. This engine is
fully backward-compatible with previous versions of the Jet engine, so
it reads and writes (.mdb) files from earlier Access versions. It
introduces a new default file format, (.accdb), that brings several
improvements to Access, including complex data types such as
multivalue fields, the attachment data type and history tracking in
memo fields. It also brings security and encryption improvements and
enables integration with Microsoft Windows SharePoint Services 3.0 and
Microsoft Office Outlook 2007
In addition, ACE provides a 64-bit driver, so can be used on 64-bit machines, whereas JET cannot.
The driver is not part of the Windows operating system, but is
available as a redistributable.[11] Previously the Jet Database Engine
was only 32-bit and did not run natively under 64-bit versions of
Windows.
As for the second part of your question, I recently installed Office 2010, and I had to download the ACE components separately. I got them from the link Microsoft Access Database Engine 2010 Redistributable. This is likely because I had installed a 32-bit version of Office under 64-bit Windows; in any case, the necessary files are easy to obtain from Microsoft.
The drivers are essentially the same when used for basic operations, and show notable difference with more complex stuff (unions, nested queries, etc).
Based on personal experience, ACE does not provide fully backward compatible results. It may open and read/write the previous .mdb format but there are changes in data type casting of exactly the same queries.
For example, when using UNION on TEXT fields, where JET used to return TEXT(255) result, ACE returns MEMO ?!
This can produce a lot of trouble in combination with BI or reporting tools like Crystal Reports.
In Access 2003 I used to import special xls files provided to us by a third party. I used ADODB for this, which worked perfectly.
ADODB is no longer an option in Access 2007/2010, and I don't think you can "query" a spreadsheet using DAO or ADO.
So, are there any alternatives?
I don't think you can "query" a spreadsheet using DAO or ADO.
You can indeed query an Excel workbook using ADO with the OLE DB provider for Access (Jet, whatever). See this MSDN article for more details.
ADODB is no longer an option in Access 2007/2010,
That is not the case. I think you must have misunderstood something, which is hardly surprising considering there is a lot of nonsense out there on the interwebs surrounding "ADO vs DAO" in Access.
I'm not exactly sure what happened when ADO classic was introduced to the Access2000 community but it seems that a lot of old-timers were left with hurt egos/pride. The marketing message from Microsoft was in effect, "DAO is now the old way of working and ADO is the new." In a deliberate move by MS,, new engine features were generally only available via ADO.
As is often the case when entrench positions are threatened, there was a counter-movement by long time Access+DAO fans. This often took the form of, "throw enough mud and some will stick." People newly arrived in AccessLand would be confused by the mixed messages. In the newsgroups, aspiring Access MVPs emulated existing Access MVPs' anti-ADO stance.
Between the 200 and 2007 releases, the Access product became IMO somewhat stale as regards the engine, responsibility for which had been handed to the SQL Server team, who had for all practical purposes given up on it: their attempts to make it comply with entry-level Standard SQL-92 were thwarted by the Windows team, whose components relied on features that flew in the face of the Standard. The ADO classic team had similarly been disbanded. Visual Basic COM, which effectively shared VBA libraries with the Office suite, was killed off in favour of VB.NET and ADO.NET was born,
The Access2007 team shook things up again. They reclaimed the engine from the SQL Server and Windows teams by taking a private branch. They ditched user level security, presumably because it was too complex for them to maintain. They added multi-valued types that arguably violate 1NF. Brave stuff! While some features could be accommodated in ADO classic by authoring a new OLE DB provider for Access, others could not. For example, full support (e.g. updating via SQL) for multi-valued data types in ADO would require a change to the ADO classic libraries which the Access team does not own.
Because DAO was owned by Access, the new version (called ACEDAO) got features the new OLE DB provider with the old ADO classic libraries would lack (although ADO was required to use the engine on 64 bit machines). However, what they did not do was to retrospectively fix DAO to accommodate the Access2000-era functionality that went into ADO only.
Naturally, the Access team promoted ACEDAO as first class citizen. Of course, the long-time Access+DAO fans were delighted: "ADO has been deprecated in favour of ADO.NET," they crowed. In truth, the net result is a mixed bag. See this thread for full details.
In your VBA project in Access click on Tools / References then find "Microsoft Excel 14.0 Object Library". This will give you access to all of the VBA Excel objects so you can do whatever you want to the spreadsheet.
As others have said running queries on the sheet is not an option. If you're used to thinking in terms of databases think about running a check on the template to make sure the headings match so you more than likely have a good file you're reading from. Then once you've verified the document setup SQL inserts on the lines with records on them into a table in an Access Database then run your queries from there. Check here for writing your SQL code:
SQL Statement Help
If you want to get more advanced in your VBA if your files are small you could run searches by setting up an object with setters/getters and store the records into a collection class then iterate across it with the data you're looking for.
I do this in some projects where I know the lists are small, gets away from reading/writing to tables when I really just want to read the data and run some real basic calculations like count the number of a particular widget and place the count on a report. Collection classes are great for this. Here's a good link for some more info on collections:
Collections in Visual Basic
Good luck!
I've written an Access 2003 application to handle internal things at my company over the past couple years and we are talking about upgrading all of our computers to Office 2007 which means Access will be updated. Is this going to cause a problem for me?
Allen Browne, Microsoft access MVP, has written a comprehensive article on Microsoft Access 2007 and upgrading:
Converting to Access 2007
Here is an article by Microsoft:
Transitioning Your Existing Access Applications to Access 2007
In case you are not aware, it is possible to try 2007 for free. I would not recommend trying on a PC that you use regularly for other Access work, it is not impossible, but things get awkward.
If you wish to run your 2003 version on 2007, make sure that you create an mde, otherwise you will run into problems. Access 2007 treats several controls in a different way, for example, textboxes with date fields get calendars attached. You will also need to check your references. I also recommend that you self-certify your projects. Other than that, I have seen posts on a number of problems, but these are usually specific to the poster.
We just recently went through this.
One issue we found was converting reports to Excel. They took that functionality out of Access, so if you do that you'll need to convert it programmatically using the Excel COM object model. I ended up writing a function to replace the old functionality but you still have a bit of juggling to do.