I have an MS Access frontend which is using a SQL database as backend. To connect, I use a ODBC connection and have created the needed entries in "ODBC Data Sources (32 Bit)"
When I will give the database to others, they will need to create this data source. I have a batch file for this so they can just run it.
If they do not run it, they will get a fault like "ODBC connection to XY failed". How could I change this error or at least write a second Message Box afterwards where I can tell them "run the Batch file XY to connect"?
When I will give the database to others, they will need to create this data source.
that is your first bad mistake and assumption. You MOST certainly do NOT want to deploy your applcation that way.
The way you deploy?
You take your accDB file, and link the tables to sql server. And you link using what is called DSN-less connections. Such connections do NOT require ANY data source to be setup on each work station.
So, ok, now you linked the tables to sql server (the production one - you probably were developing local on your developer PC and using a local copy of sql server express edition.
So, so now you link the tables to THEIR server, and then you now compile the accDB down to compiled executable version of Access - a accDE.
You are now free to deploy this "application" to any and all workstations for that company - and they do not have to re-link tables, do not have to setup a data source, and in fact they don't have to do anything, but simply run/launch the applcation.
How to make and get a dns-less connection?
Well, the MOST simple way is to ALWAYS, but ALWAYS ALWAYS create the linked tables using a FILE dsn. In fact, when you launch the ODBC connection manager from Access, the default is to use a FILE dsn. Never, and do not use "system" or "user" dsn.
If you link the tables using that FILE dsn, then Access converts them to DNS-less connections. At that point, you can even delete the DSN you created - access 100% ignores the DSN, and you don't need it anymore.
Next up:
If you been using nc 17 or nc 11-18 drivers? then yes, each workstation MUST have that same driver installed. Or, you can use the older "legacy" sql driver. But be careful - the legacy driver does not support datetime2 columns data types.
So, MAKE double, triple, quadrible sure that you not using data types and columns that require the newer drivers.
Right now, for some of the larger sites, we STILL use the older "legacy" driver, since that driver is installed at the OS level, and has been installed on every copy of windows going back to windows xp - in fact windows 98SE edition started shipping that driver. So you can 100% assume that the legacy sql driver is and will be installed on each workstation.
And by using + adopting dns-less connections, then no setup of the connection on each workstation is required. As long as those work stations are on the same network to sql server when YOU linked the tables, then they are good to go.
Now, on some sites, we actually can't even be on site, and we can't even pre-link to their sql server. So, what we do is on applcation startup, we check the current link for a linked table, and if it does not match a little external text file we ALSO included when setting up the work station, then we use VBA code to re-link the tables on startup. But once again, re-link of tables in VBA is easy, and again does NOT require ANY KIND of "dsn" or odbc setup on each work station.
And in fact, another way we used to do this is have a table in the front end, and it had one record, and that record had the connection string. So, right before deployment, we just edit that one record table in the front end to have the correct connection to their sql server. And once again, on startup , we check a linked table, and see if the connection strings match, if they don't, then we run the VBA re-link code, and once again, zero configuration and zero need exists to setup anything at all on each work station.
So, as a general rule, every dog, frog, insect that deployed access applications? We setup some re-link code and check that link on startup. In fact most developers have done this even without sql server - and even when using a access back end, then re-link code is included to resolve this issue.
but, be it linking to a access back end, or sql server back end? Some time of link check and system is assumed to have been cooked up by you, and this code will run on startup to check if the linked tables are pointing to the correct location.
But, be the back end oracle, sql server or whatever? You can create what is called dsn-less linked tables. As noted, you can use VBA to do this, or in fact you can use the linked table manager ---- as LONG AS you use a FILE dsn when you linked, then access coverts that to dns-less for you, and you be good to go.
so, in effect, you don't have to test/check/know for a odbc fail, since you checked the correct connection string on startup.
However, there is a way to trap, and check for a odbc failure, and this involves using a DIFFERENT way to connect, since we all know that if you have a odbc fail, you are duck soup (you have to exit Access, and there is NO KNOWN way around this issue - (well, except for testing if you can connect, and you do NOT use a linked table - since as noted once a odbc connect error triggers, it is game over.
The way you do this "alternate" test is like this:
Function TestLogin(strCon As String) As Boolean
On Error GoTo TestError
Dim dbs As DAO.Database
Dim qdf As DAO.QueryDef
Set dbs = CurrentDb()
Set qdf = dbs.CreateQueryDef("")
qdf.connect = strCon
qdf.ReturnsRecords = False
'Any VALID SQL statement that runs on server will work below.
' this does assume user has enough rights to query built in
' system tables
qdf.sql = "SELECT 1 "
qdf.Execute
TestLogin = True
Exit Function
TestError:
TestLogin = False
Exit Function
End Function
So, above does not hit or use a linked table. And a HUGE bonus of above? Once you execute that above valid logon, then any and all linked tables will work - AND WILL WORK without even having included the user/password in that connection string for the linked table. This is in have a huge bonus in terms of security, since now you don't have to include the user/password in the linked tables which of course exposes the user/password in plane text for all users that could look and see and find the sql user/password used.
In fact, what this means is that you can link your tables, but NOT include the user/password when you link the tables!!! - this is a HUGE security hole plugged and fixed when you do this.
So, once a valid logon has occurred (such as above), then any and all linked tables will now work, and work without even having included the user/passwords in those linked table connection strings.
As noted, the other big bonus is that you can use the above code to test for a valid connection, and avoid that dreaded "odbc" error, since as noted, if a odbc connection error is EVER triggered at any point in time, you MUST exit the applcation - no other way out.
However, it should be noted, that if you ever are going to use a wi-fi connection, or say cloud based sql server say running on Azure?
In that case, often with wi-fi, or a cloud based edition of sql server, then of course such connections over the internet are prone to minor and frequent dis-connects.
ODBC was developed long before the internet, and long before people would do things like connect access to some cloud based sql server running, and using a connection over the internet. But, if this turns out to be your use case, and deployment case?
Then you have to bite the bullet and ASSUME and ENSURE that you now adopt the nc 11-18 drivers. (I would go with nc17). These new drivers are now "internet" aware, and they are able to gracefully handle minor dis-conects, and in fact automatic re-cover and re-connect.
So, if you are ever going to use wi-fi, or connect to cloud based server? Then yes, you have to link the tables using say nc17 newer drivers, and you ALSO MUST THEN ensure that the same driver version you linked tables with is to be installed on each work station. You still don't have to setup any dsn connection and all that jazz - but you do have to ensure that the driver you used is ALSO installed on those work stations.
As noted, for larger deployments, we thus use the standard "legacy" sql driver, as it would be too painful to go to all work stations and install this driver.
However, we had one location, and for months they were experience in odbc connection failure. We had them replace a router, and even a network card on a server - but the problem still remained.
We suspect that some workstations had aggressive power management turned on, newer windows 10-11 will often put the network card to sleep, and thus when using access, we were seeing odbc errors. So, for that company, we had them install nc17, and linked access to sql server using that driver, and the problem went away (because those newer drivers now have built in re-connect ability - this is a relative new feature of ODBC, and one that legacy systems and drivers don't have.
I have three Access database MDB files with various tables I need to upsize to SQLServer. I need to be able to update the data regularly. I am using an SSIS package in Visual Studio. I have it set to use the 32 bit version for this project. I have one of the databases running just fine. Using the same techniques on the next database I create an OleDb connection manager using the Access 16 connection and the connection tests fine, I drop down the tables drop down and it finds the table names just fine. I pick a table and hit ok and it comes back with:
Exception from HRESULT:OxC0202038
I got these databases from another source. Two of the three were set without security. Being older MDB's they have the ability to have user level security. The table in question was in the one database that had security set to admin only. The deceiving part is that the oledb connection could find the table names at all with security set so I should not be able to read them. The ambiguity of the error message was not all that helpful either. But, once I reset the user level security to allow full access things worked fine.
While testing an Access file after restructuring I frequently flipped between credentials for the UID and PWD of the ODBC connection string, but something I did recently has caused Access to no longer show the full connection string.
I have 4 production pass-through queries and 1 test pass-through query. The test pass-through query shows the full ODBC connection string, but the 4 production pass-through queries show only ODBC;DSN=schema_name;. I tried restating the ODBC connection:
a) I click the three dots
b) The "Select Data Source" box opens
c) I select the data source
d) I choose "Yes" to save the password in the connection string.
Yet after this it still only displays the abbreviated connection string. What do I need to do to have MS Access display the full connection string?
Should the connection string UID and PWD always match that which is saved in the ODBC data source configuration box?
Using Access 2010
Saved in .mdb (Access 2000) format
User DSN: MySQL ODBC 5.3 Unicode Driver
System DSN: MySQL ODBC 5.3 ANSI Driver
The saving of the UID/password is determined how you FIRST created the table link. If you checked the “save password” in the connection string, then any re-linking and including the uid/password WILL BE saved and will be CLEARLY visible in the string.
If you did NOT check the box “save password” then re-linking and EVEN WHEN YOU include the uid/password, it will NOT be saved in the connection string. And thus if you have not logged into that server, then opening such a linked table will cause a logon or an odbc connection error. However, if you logged into that table, then access caches the uid/password for that session.
So “how” you created the link will determine if the uid/password is saved. The tabledef attribute that controls this setting is thus:
MyTableDef.Attributes = DB_ATTACHSAVEPWD
As a general rule it is MUCH better to NOT include the uid/password in those links. Best to execute a logon at the start of the application. This also means that you can use different uid/passwords and NOT have to re-link the tables. I don’t think that querydefs have this setting, but they will ALSO work without the uid/password if the user has logged on to the database.
So, to answer your question: An option (attribute) setting exists that will cause the uid/password to be saved, or not saved. This option OVERRIDES the cause when INCLUDE the uid/password in the connection string – it will be removed and NOT saved if the table def does NOT have the above attribute setting that allows saving of the uid/password in the connection string.
Here is a great article that explains how to have all your tables connect and work without having to include the uid/password in the connection. The “trick” involves simply executing a logon at the start of your application.
Power Tip: Improve the security of database connections
http://blogs.office.com/b/microsoft-access/archive/2011/04/08/power-tip-improve-the-security-of-database-connections.aspx
follow up:
As a general rule when you using Access with SQL server, you use linked tables. You then can continue to use Access as you always did. You can thus simply bind a form to that linked table to SQL server and thus you have forms and reports that work without the need for writing ANY code. So both tableDefs (linked ones) and querydefs have a connection property.
It looks like querydefs don’t have the “save password” attribute I outline above. This likely means that if you specify a DSN, then no password etc. is saved since it is expected in the DSN. So, try removing the DSN part – by doing this, you are creating a DSN less connection. Leaving out the DSN part should allow you to save/specify the uid/password in the string. I would also check for possible different behaviors if using a file or machine DSN (one uses a file, the other uses the registry).
We have the problem, which I think should be easily resolvable, but just not sure how.
We have the Windows 2003 Server with the Classic ASP application on it. The MSAccess database is used for data storage.
The application is designed in the way that it has a lot of includes.
The .asp page may open the DB connection and close it in the end of the page. At the same time the include that is included on the page may have the same database open as well.
The problem is that on the second open we're getting an error:
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Microsoft Access Driver] Could not use '(unknown)'; file already in use
This is on our local configuration only - we don't own that project, but are helping customer to fix some items. Everything works just perfect on Customer side.
When we set the read-only access to the database this error is not shown.
So, it seems that the ADODB.Connection is opening the database in exclusive mode.
Anyone has any ideas how to fix that?
Thanks
Ok. The issue was resolved. As I was saying in the question - the resolution was VERY SIMPLE. Instead of setting the IUSR_* Write permission to MDB file only, it was necessary to set the Write permission to the whole folder where the MDB file is stored. Strange, because I don't see any additional files created (meaning, like .ldb file, which is created during an exclusive DB open). But, it works now!
As far as I remember from using Access in my first classic ASP days you can't have more than one connection opened in the same time pointing to the same physical .mdb file because once it's opened, it's locked. That's what I learned the hard way.
The solution for me was using one single Connection. Having very small website to manage, I just used Application level connection object, created and opened once in global.asa then used in all pages.
However this is not good for ordinary websites so you can write file called "database.asp" in there create and open the connection then include that file and use the connection object in your code, not forgetting to close it in the end of every page.
Hope this makes sense, I'll clarify if needed.
I cannot update the links in my access to a new ODBC driver.
I believe it to be that OpenEDge 10.1C is not doing a handshake with Access.
The dns will import external data into excel. The error is "error(-7748) the is no message for this error"
Most "weird" errors involving SQL and Progress are a result of the fact that Progress stores all data as variable length. Furthermore most of the data in most Progress databases is created, updated and manipulated by 4GL programs and those programs have no awareness of nor any sensitivity to SQL's ideas regarding column width.
Your first line of defense when you get a strange error trying to query a Progress database with SQL should be to run dbtool (on the db server) to fix any possible SQL width issues. Simply run dbtool (found in the Progress "bin" directory, $DLC/bin/dbtool if the OS is UNIX, use "proenv" to get a command prompt and then %DLC%\bin\dbtool if you are running Windows) and select option 2. You may want to script this and run it automatically if you frequently have issues.
Progress ODBC error -7748 can be solved by adding a registry entry. This discussion explains the workaround and what it does.
Essentially, the registry key:
HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\[Your data source name]
should be a string value entry named 'Workarounds2', and its value should be set to 8192.
See:
http://media.datadirect.com/download/docs/odbc/allodbc/index.html#page/odbc/workaround-options.html