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.
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).
This question is not about dsn-less connection strings in MS Access per se (which I can build successfully). The following string worked just fine last week when connecting to our iSeries from MS Access 2010 on Windows 7. Over the weekend, our IT group installed a variety of anti-virus systems and now the string works intermittently. However, the behavior is extremely peculiar and takes a bit of explaining. This is the string:
ODBC;Driver=iSeries Access ODBC Driver;System=nnn.nnn.nnn.nnn;UID=myuid;PWD=mypwd;DBQ=mylibraryname;Initial Catalog=mylibraryname;MGDSN=0
It is assembled in a loop that runs through a table of connection parameters, building linked tables on the fly (first dropping them if they already exist then adding them to the tabledefs collection). There are about 12 linked tables which reside on two different iSeries LPARs (two different IP addresses specified in the "System" connection parameter). The tables reside in several different libraries so the parameters "DBQ", "System" and "Initial Catalog" vary in each iteration.
Today the loop only works for ONE of the LPARs (one IP address) and for the other I get error 3011 ("The MS Access database engine could not find the object MYLIBRARYNAME.TABLENAME..."). This error occurs when the following line of code attempts to execute:
CurrentDb().TableDefs.Append tblLinked 'tblLinked is of type TableDef
I can manually create the linked table objects using the MS Access 'External Data' menu for ODBC using named DSN's created with the Windows ODBC utility. I can refresh all linked tables using the Linked Table manager. I just can't use VBA to add linked tables to the tables collection for tables on one ip address, and then add linked tables to the other ip address in the same Access session. If I close and reopen Access, I can create a linked table pointing to either system using the same VBA. I just cannot subsequently create a linked table to the other ip address using VBA.
I looked at IBM's connection parameter options and added the parameters for DBQ, Initial Catalog, CONNTYPE & LIBVIEW, none of which were needed last week. I ran compact/repair and then after more research created a new database and imported all objects, then converted the db to a .mdb format (Access 2007) and ran compact/repair. No help.
What's nuts is that if I close the Access application and reopen, my code can append a tabledef to whichever ip address is mentioned first, but any attempts to append a tabledef that links to the other ip address fail with error 3011. Each time I close and reopen I can link to whichever ip address I want, but not the other. This is 100% repeatable. To be clear, I have to close the Access application, not just the current database. Upon reopening I can connect to the whichever IP addr I want, but not the other.
The code worked last week, but not today (first day back in the office after the long weekend).
I've decided that appending an ODBC tabledef to the tabledefs collection causes Access to verify the existence of the table, but not by using the connection parameters. Instead, the .append method triggers a verification process that uses some setting that persists but that I cannot find it to reset its value. How could connection information be cached and not reset by the connection string??
Can anyone point me to where I might look next?
I have an Access 2007 application (previously in Access 2003) that is running into some performance issues when the linked database tables are on a network drive. In 2003 the application worked perfectly fine. Now in 2007 the speed of data retrieval using sql and a recordset is degraded pretty poorly. The exact area that i am encountering the issue is on:
DIM rs AS NEW ADODB.RECORDSET
rs.Open tsSql, CurrentProject.AccessConnection, iKeyset, iLock
The iKeyset is set to 0 and iLock is set to 3
the rs.Open command is taking from 4 - 5 seconds which is an issue due to the fact that on some of my forms this can happen multiple times on load.
any thoughts?
EDIT: not to mention that I believe that opening and saving forms in design view appears to be slower than normal under these circumstances.
Depending on the SQL statement involved (i.e., your variable 'tsSQL' above) , your recordset should open instantly whether ADO or DAO.
Ideas that come to my mind: is your connection persistent? This seems to cause more of a delay in 2007 than in 2003. Maybe it's dropping and re-establishing the connection each time. With forms this happens when your recordsource is blank and set in code, so one is advised to always have a recordsource such as "tblBlankTable" (a small one-record table just to keep the connection alive all the time in a form that is always open). The 4 to 5 second delay is about what you get when this is not in place. Try making sure you have a form connected to your DB all the time when running your rs.open and see if that works. Possibly you might need a form with an ADO connection open in your case. Lots written out there on Access forums about this.
Is it faster when you are the only user versus when others have the DB with a lock file open? That is the tell-tale sign.
Another idea is whether you indexed everything correctly when you upgraded. Did the underlying DB stay the same or get upsized from MDB to ACCDB? You didn't indicate what is in the tSQL, so maybe you are joining on non-indexed fields or something that is causing that particular tSQL to run slowly and just need to add a primary key.
If your 'tsSQL' involves queries, I've read that when upgrading it is important to recompile all your queries -- go into design mode with each one, then run them, then save them again.
You could try connecting to the DB with your own connection string -- there is one format for MDB/Jet and another for ACCDB/Ace. There are providers for both that one usually uses from Excel to MDB or ACCDB, but maybe could work within Access, at least to debug your problem.
There is a hotfix Description of the Access 2007 hotfix package (Access.msp): August 26, 2008 that mention performance issues however this is very likely included in Access 2007 SP2. Click the Office button >> Access options (lower right hand corner) >> Resources tab and see what the section titled about Microsoft Office Access 2007 shows. Mine states 12.0.6535.5005).
Does anyone know how to import .dbf file into MS ACcess 2007?
Do you want to do this programmatically?
MS-Access has option to import the tables OR you could create a Linked Table.
EDIT: Open the MS-Access MDB, goto tables. Right click -> Import -> Choose the appropriate database type (could be dbf in your case).
Well a VBA approach to pragmatically pull this information is to create a connection object connecting to the directory of the tables you want to pull from.
After that open a recordset to query what you need from the tables against that connection. A big benefit of directly connecting and scanning is that your not bulking up tables in your database to push you closer to your next repair/compact.
In order to get this connection however I needed some kind of ODBC connector, something the network admins came and installed behind my back when I switched to a new work PC and it suddenly broke upon connection. If this is something you would be using on other users PCs who won't have access to this (if this is a query you will be performing on a normal basis) it may not function properly for others...