I usually make applications with the front end in Access 2003 - 2007 and the back-end on SQL Server 2008. When I create an ODBC to link the tables in access I have two choices in the ODBC Data Source Administration page on my Windows XP PC:
Server 2008: SQL Server Native Client 10.0 v.2007.100.2531.00
SQL Server v. 2000.85.1132.00
Which of these should be better and compatible on PCs with just Access 2000?
The native client has support for some additional (more advanced?) features of sql server 2008 (and 2005 I believe).
However, out of the box, you are far more likely to find the standard sql server driver installed on the computer.
Unless you are using some type of installer, or some other software installs this native client driver, then you are best to stick with the default non native driver for maximum compatibility. And, there is just the plain issue that the standard driver is most likely to be already installed on your client side computer.
So, that new native driver not going to be installed by default, and you likely have somewhat better luck with the non native default driver. I had a few issues come up with exporting date columns when using the new native driver (can't recall just right now what the issue was, but there was an issue).
Note that your connection strings are/will be slightly different for the native driver, and if you have some re-link code, that code will fail on computers without the native driver. So, while you have both on your computer, you can't assume this will be the case on other computers. So, you should have special and good reaons to choose/use the new native drivers for 2008/2005, but if not, then use the standard ones.
Related
We've got some MS Access 2007 apps here. I'm responsible for one. Normally, it never gives any problems. I haven't heard from the users of this app for over a year, until today. It was written years ago by someone (I don't know who) that is long gone, with little documentation. We're in the process of replacing all of our Windows 7 machines with Windows 10 machines. At first I thought that was the issue. However, one of my colleagues, who is responsible for a number of Access 2007 apps, said that his users are able to use their Access apps with no problem.
Looking back at the user's error, it says simply, "ODBC - call failed". No error number; just that. So, my next thought was maybe there was a missing DSN on the new Windows 10 machine. However, I asked the PC tech to check one of the working Windows 7 machines. He told me there were no DSN's in them. I'm not an Access developer, so I asked my colleague, who does do Access development, what he could discover. He found that the tables are all linked tables from a SQL Server database. Looking at what he was referring to (now that I know where to look) I saw what he meant. The connection to each of those tables uses trusted connections. They're all pointing to the correct SQL database server. That server is there. When I got into SSMS I could easily see data in the tables.
So, what could be causing that error to occur, especially since it doesn't look like it needs a DSN to make a connection to the SQL db?
I presume your Windows 10 is 64-bit.
And probably your Access is 32-bit.
Its important to know!
If my assumptions are correct, you need to use the 32-bit version of ODBC admin to setup the DSN.
The 32-bit version is 'C:\Windows\SysWOW64\odbc32.exe'
The 64-bit version is 'C:\Windows\System32\odbc32.exe'
32-bit Access will look for a DSN setup using the 32-bit version of ODBC admin, even on a 64-bit OS. If you setup the DSN with the 64-bit version of ODBC admin, then a 32-bit Access will not see it!
Go back on the Windows 7 PC, and check exactly how the DSN is setup.
Is it a System, User, or File DSN?
Which drivers are installed for SQL Server?
(There are various different ODBC clients available for SQL Server.)
Replicate this DSN configuration when you create the DSN on Windows 10.
It sounds like you using the 'SQL Server Native Client' on Windows 7,
so make sure to install that on Windows 10.
See: Installing SQL Server Native Client
I tried to migrate my Classic ASP application with its Access DB from Windows 7 Professional to Windows Server 2012.
For standard script without accessing access db, it's working fine.
But I got error when the script use access db, by the following:
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Driver Manager] Data source name not found and no
default driver specified /includes/public.asp, line 64
Here is my connection string
strConn = "DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=" & server.mappath("../private/apps.MDB")
In application pool, I've set
.NET Framework Version = No Managed Code
Enable32Bit Application = True
ManagedPipelineMode = Classic
What am I doing wrong?
The "Microsoft Access Driver" is the desktop driver installed when Office Access or the Office Access Redistributable is installed, it is not intended for use in server-side applications. The current Access driver is also known as ACE (Access Connectivity Engine) and replaces the JET engine for single-user desktop applications only.
Instead, please use the JET 4.0 OLEDB or ODBC driver (ODBC is preferred). This driver is included in MDAC which comes with Windows Server out-of-the-box. The connection string template is this:
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\somepath\myDb.mdb;
OR
Provider=Microsoft.Jet.ODBC.4.0;Data Source=c:\somepath\myDb.mdb;
Note that the JET 4.0 driver is only available in 32-bit mode (but you've already set your application-pool to 32-bit so this won't be an issue).
Note that JET is effectively obsolete at this point (its successor, ACE, is only intended for use in single-user desktop applications) as evidenced by its availability only in 32-bit versions. Server-side and multi-user applications should use SQL Server (SQL Server now supports "LocalDb"-mode which introduces a simpler working experience, similar to Access, and it's available in Express Edition). If you absolutely need something simple and low-resource I would suggest SQLite, however you will be responsible for using the SQLite API correctly in a multithreaded/concurrent environment like a webserver (including Classic ASP).
Update:
I'll revise my answer to warn that using LocalDb with ASP.NET, or server applications in general, is inadvisable - and of little point, actually - if you're using LocalDb then you already have SQL Server installed, and if you already have SQL Server installed then you might as well use it in "normal mode" rather than LocalDb mode.
I have created System DSNs to a MySQL and Oracle database and I have been able to use these DSNs to create linked servers in my SQL Server database and all is working fine.
However, I am trying to create a report in BIDS 2008 / Reporting Services 2008 R2 and I am unable to get these system DSNs. When I try creating a data source, I select Type as ODBC, click Edit, my System DSNs on that same machine aren't displayed.
I will be very grateful for any help. Thanks
Are you using a 64-bit machine? If so, be aware that on a 64-bit machine there are TWO ODBC Data Source Administrators, one for 32-bit and one for 64-bit drivers. If you create a System DSN in either one, it is not visible in the other.
The 64-bit version is usually in C:\Windows\System32\odbcad32.exe
The 32-bit version is usually in C:\Windows\SysWOW64\odbcad32.exe
I'm not sure which version Reporting Services is looking for but try opening both versions up and re-creating your DSN in the one where it's missing (assuming there are both 32-bit and 64-bit drivers for your data source).
I have a Winforms desktop app that need to read/write data from/to a MYSQL database. The MYSQL server is on a machine that runs on Linux OS. I need to know if a .NET connector is to be used or an ODBC connector?
Also, considering that I do not need remote access to MYSQL server, is a connector sufficient to access the server from the windows desktop? Do I need to do something on the server side? I've been looking around and getting mixed signals, some people said a web service is required while others said no.
I need to know if a .NET connector is to be used or an ODBC connector?
I never connected to MYSQL before, but i think you can use these data provider or, ODBC too.
Is a connector sufficient to access the server from the windows desktop?
Yes. A valid address to your server is all you need to access it, using data providers or ODBC. Of course, your database need to be up and running too.
Do I need to do something on the server side?
Just install your MYSQL database.
Maybe this link will help you.
I have an application written in MS ACCESS 2007 using VBA, connecting to an SQL Server at the back end. Both Access and SQL Server are running locally.
My machine runs Access 2010 and MS SQL Server Express 2008 R2 (both 32-bit, on WinXP) with no problem.
I have another machine, Win7 64-bit, running both Access 2010 and SQL Server 2008 (NOT R2) 64-bit.
When I run the Access application on the 64-bit machine, I have a drop down box to select the SQL Server which holds the various databases. When I select the server, after a few seconds I get an error:
Run-time error '-2147024703 (800700c1)':
Automation error %1 is not a valid Win32 application.
When I select the Debug option, the yellow arrow points to:
Set oServer = New SQLDMO.SQLServer
The next line is:
oServer.Connect ServerName, strSQLUser, strSQLPwd
In the watch list, I can see that ServerName, strSQLUser, and strSQLPwd hold the right values to access the SQL Server. I've tested these in sqlcmd and successfully was able to query tables.
Can anyone please help me out on this one? I'm not sure what to do next.
Seems like you've got registered a 32-bit SQLDMO on your system that is being used for connection to the 64-bit instance. Check your registry / file system for SQLDMO.dll versions and register the correct one.
Also check MSDN "Installing SQL-DMO" because SQLDMO was scheduled for remove after SQL Server 2008 R2:
Avoid using this feature in new development work, and plan to modify applications that currently use this feature.
SQL Server Database Management Objects (SQL-DMO) has been removed from SQL Server 2008 R2 Express and the SQL Server 2008 R2 Feature Pack. SQL-DMO also does not support Database Engine features introduced after SQL Server 2000. We recommend that you modify applications that currently use this feature as soon as possible. If you must support SQL-DMO, install the Backward Compatibility Components from the SQL Server 2008 Feature Pack from the Microsoft Download Center. Do not use SQL-DMO in new development work; use SQL Server Management Objects (SMO) instead. You can obtain the SMO documentation by installing SQL Server 2008 R2 Books Online.
Thanks for this.
I looked to find SQLDMO.DLL 64-bit version, but although using the Backwards Comparability package for x64, installing using the MSI did not do the job.
I had to manually extract the files and place the correct version (which is ~2MB larger than the x86 version as an indication to knowing which one is the x64) and then run 'regsvr32 sqldmo.dll ' in the command line (very important: need to run cmd as Administrator for this to succeed).
After the module has been registered, my Access front end run great.