MSAccess 2007 changing connection properties in form - database

I would like some help in creating a form with-in an MS Access front end to select a database/database server for the access backend.
A little history first;
I created a MSAccess 2007 acccdp database, it was designed as a single user to be run locally. (For a university research project with little or no funds for this).
Eventually there was a need to expand the database to be used by several people at once in the same office so what i did;
Install SQLExpress 2008r2 on a desktop.
Used Database Tools > Move Data > Sql Sever to migrate the tables to the new SQL server.
Now I want to create a second test database for development/training etc... Also, I need to adjust the properties for a different database sever (at home).
So I figure I need a form to auto exec (rather than the switchboard) which will allow you to select the database server and Database to join the linked tables to, then if successfully connects to open the switchboard.
I can create the form, but i need help with the vba to adjust the database connection properties.
I am just trying to help this project and am not a programmer in any way.
Thanks in advance
Roger

If your choice is between two connections, you can check if the existing connection is working and if not, switch to the second. However, a button may still be the best bet. This snippet works for me, but it sets the connection timeout to just a second, so the server may be available if you had only waited a little longer, and even with this time out, there is enough of a delay for an impatient person to start clicking.
Function IsSQLServer() As String
''Reference Microsoft ActiveX Data Objects x.x Library
Dim cn As New adodb.Connection
''http://msdn.microsoft.com/en-us/library/windows/desktop/ms676718(v=vs.85).aspx
''Provider=sqloledb
cn.ConnectionString = ServerCon & "Connect Timeout=1;"
On Error Resume Next
cn.Open
If Err.Number <> 0 Then
IsSQLServer = "No;" & Err.Description
Err.Clear
Else
If cn.State = adStateOpen Then
IsSQLServer = "Yes"
Else
IsSQLServer = "Maybe"
End If
cn.Close
End If
Set cn = Nothing
End Function

Related

Error when opening ADODB recordset using odbc dsn in MS Access

I have a MS Access application that has been in use for at least 10 years. Recently I moved my work to a new development machine with Office 365 and SQL Server Express 2019 installed. The machine OS is Windows 10 Pro. In my old machine my application would run just fine. There is a query using a stored procedure that retrieves a piece of data from a table in the SQL Server backend. I call this procedure using a ADODB recordset based on the stored procedure output. All my calls use a connection string based on an ODBC DNS. This connection string works fine on the new machine when relinking tables to the SQL Server backend, but when I use it in the ADODB connection I get an error "[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified". On the old Windows 7 development machine this ran fine. It also runs on the client's machines which are Windows 10 and Office 365. The code that raises the error follows. The error occurs at the open connection line. The connection string is: ODBC;DSN=VROM;Trusted_Connection=Yes;APP=2019 Microsoft Office system;DATABASE=VROM1.
Set con = New ADODB.Connection
con.ConnectionString = DLookup("Link", "tblLinkData", "Use = True")
con.Open
Set rs = New ADODB.Recordset
My question "Is there a setting in SQL Server that could be causing this error?". As far as I can tell both systems are set up the same, but there is obviously something different between the two. Is there another reason this could be working on one system and not another?
Hum, where to start?
Ok, first up, if you using the ODBC panel to create a ODBC connection, then you NEVER were actually using a ADO connection in that DSN config = ODBC!!!!
That means you been feeing ADO a ODBC connection string. you can do this, but at least lets be aware of what is going on.
Next up:
Are you running the SQL browser service? You MUST do that now!. Don't know if you installed a later version of SQL SERVER, but a few versions ago you will find now that you MUST run the browser service.
This one:
The reason of course is that you can (may) have multiple instances of sql server running, and the default instance (SQLEXPRESS) now MUST BE specified. As noted older instances did NOT have this requirement. And to "resolve" the multiple instances, you now must run the SQL browser service. As noted, this was NOT a requirement in the past - it is now. That browser service is what connects the IP/server name to the instance, and you now in most cases have to run this.
There are exceptions, but you don't want much pain.
Next up:
For a VERY long time, it is recommended for Access linked tables you use a DSN-less connection. that way then at deployment time to all workstations, you don't need to setup a DSN on each workstation.
And if you link Access tables using a FILE dsn (not system or user), then upon the table link process, access BY DEFAULT converts all table links to DSN-less. That means once you linked, then you could even delete the DSN - you do NOT need it anymore.
Again: this ONLY holds true if and when you create a FILE dsn, and use that to link the tables. So, that takes care of the DSN-less linked tables.
Note that if you were to modify the DSN, you would have to link, since I just told you by default access creates + uses dsn-less links (assuming you used a FILE dsn to link).
now, you CAN of course use that SAME dsn for ADO, but that means you are feeding ADO a ODBC driver connection!!!
If you want to create a real ADO connection, then you would/could/should say use this:
Dim strCon As String
strCon = "Provider=SQLOLEDB;;Initial Catalog=TEST4; " & _
"Data Source =.\SQLEXPRESS;Trusted_Connection=yes"
Dim conn As New ADODB.Connection
conn.ConnectionString = strCon
conn.Open
Dim rst As New ADODB.Recordset
rst.Open "SELECT * from tblHotels", conn
Do While rst.EOF = False
Debug.Print rst!HotelName
rst.MoveNext
Loop
Now now how I used a "." for localhost. That could be replaced with (local), or in fact the computer (server) name say like this:
strCon = "Provider=SQLOLEDB;;Initial Catalog=TEST4; " & _
"Data Source =ALBERTKALLAL-PC\SQLEXPRESS;Trusted_Connection=yes"
Next up, make sure you enabled the TC/IP connections.
here:
However, since your case all along you actually been using ODBC driver with ADO, then I would not rock the boat.
But, check your settings as per above.
Since linked tables, and quite much everything else is DAO + odbc?
then I would probably not introduce ADO into that application for JUST calling + using sql server store procedures.
I as a general rule would say use this;
with currentdb.tabledefs("qryPT")
.sql = "exec MyProcName"
.execute
end with
Or, if it is to return data, then I would use this:
dim rst as DAO.RecordSet
with currentdb.tabledefs("qryPT")
.sql = "exec MyProcName"
set rst = .OpenRecordSet()
end with
So, I am hard pressed to find a reason to use ADO. Now of course since you been using ADO, then I guess I would continue to do so.
but, check the browser settings. And if the tables were linked using a FILE dsn, then they are dsn-less.
You could try feeding the ADO connection a existing connection from a existing linked table.
eg:
strCon = CurrentDb.TableDefs("dbo_tblHotels").Connect
strCon = Mid(strCon, 6)
Dim conn As New ADODB.Connection
conn.ConnectionString = strCon
conn.Open
Skipping the first 6 chars skips this part:
ODBC;DRIVER=SQL Server;SERVER=ALBERTKALLAL-PC\SQLEXPRESS;
UID=AlbertKallal;Trusted_Connection=Yes;APP=Microsoft Office 2010;
DATABASE=Test4;Network=DBMSLPCNM
So once again we are feeding ADO ODBC connection string.
(of course above connection string is one line).

Use database with linked tables in Access 2000 or use the ADODB.RecordSet - Which is better?

I am reworking old VB6 apps into VB.NET with Visual Studio 2005 and all of them suffer from the same problems.
One of those is, access the DB2 database by using an Access 2000 file which has links to the tables and second approach is, using ADODB.RecordSet with concatenated string SQL queries directly run on to the database.
I know I can use Linq which is the right tool for the job, but I don't have time to learn it at the moment. I have to finish this job quickly.
Examples:
Function selectNA_FromMyTable_ByNA(ByVal na As String) As String
Dim sql As String = "SELECT na FROM DB2Scheme.MyTable "
sql = sql & "WHERE (na = '" & na & "')"
Return sql
End Function
and
Function selectNA_FromMyTable_ByNA(ByVal na As String) As String
Dim sql As String = "SELECT na FROM DB2Scheme_MyTable "
sql = sql & "WHERE (na = '" & na & "')"
Return sql
End Function
where DB2Scheme_MyTable is link to DB2Scheme.MyTable table.
I don't like mixing approaches although they both work properly.
Which is better approach?
Which approach would be better for debugging? For example, how can I detect that the user using the application does not have privileges to write or read data from a certain table in the scheme?
well certainly eliminating the Access database would be ideal. i assume in the prior model, the Access database also served as the front-end? if you're moving to .net, then i don't see the point in keeping the access database. go directly to the db2 database, just be mindful of the database drivers that may need to be installed when distributing this app. less of a problem if its a web app.
generic error handling in .net should reveal if users have access issues. you may want to check that up front when your application is launched if your application is going to use the users credentials, and not a user id of its own to access the database. I am not sure this should be something of a concern when rewriting the app, are you not using the same authentication, or logon credentials used in the formal app?

Error using SSMA to migrate Data from Access to SQL Server

I am trying to use the SSMA to migrate two Databases from Access 2007 to SQL Server 2014. The SSMA recognizes the Access DB's but the tables and queries show as zero. I have ammended the permissions to allow admin control and these are copies of the original DB's but the tables don't show up. Is there something I could be missing?
I had the same problem, and after some hours looking on this it seems that one property "SSMATableState" on the tables hides them in SSMA.
Probably SSMA added that after being used, I guess...
In Access add a module and this code, run it to remove that:
Sub tabsSSMAfix()
Dim t As TableDef, a, p
Dim db As Database
Set db = CurrentDb
For Each t In db.TableDefs
If (t.Attributes And dbSystemObject)=0 Then
Debug.Print t.Attributes
Debug.Print t.SourceTableName
For Each p In t.Properties
Debug.Print t.Name; " "; p.Name; "="; p
If p.Name = "SSMATableState" Then
t.Properties.Delete "SSMATableState"
End If
Next p
Debug.Print
End If
Next t
End Sub
Had the same problem recently.
Make sure you are using the connection called:
Native OLE DB\Microsoft Office 12.0 Access Database Engine OLE DB Provider.
You know you are using the right provider when you can preview the data.

Script to replicate SQL Server data dynamicaly

I have an access 2010 application with a SQL Server database.
But I need to do an offline version. So I thought I would create a local SQL Server database on their computers then they can run a script to update their data before they go on the road.
NOTE: There won't be any sync. The data in offline mode is only for read-only and any changes will be lost.
I tried with Management Studio like this:
But I realized that the data is hard coded instead of doing inserts from selects.
Is there any easy way to create the script?
What I have so far is my pass through query in access to create the backup of my online database.
Then I have my pass through query to restore the backup to the local server.
The only problem is how can I build the connection string for the second query. It's currently set to this one
ODBC;DRIVER=SQL Server;SERVER=010-068\SQLEXPRESS;UID=marcAndreL;Trusted_Connection=Yes;DATABASE=SMD
but because it's a different database for everyone, it won't work.
How can we build a custom connection string?
I am using SQL Server Express 2012 and Windows Authentication, so using the answer provided here, I find this works for me:
Sub TestCon()
Dim cn As New ADODB.Connection
cn.Open ServerConLocal
End Sub
Function ServerConLocal()
''OleDB Connection
ServerConLocal = "Provider=sqloledb;Data Source=localhost\SQLEXPRESS;" _
& "Initial Catalog=Test;Integrated Security=SSPI;"
End Function
For an ODBC connection string in a Pass-through query, this works for me:
ODBC;Driver={SQL Server Native Client 11.0};Server=localhost\SQLEXPRESS;Database=test;
Trusted_Connection=yes;
Take a look at download-only articles for merge replication. MSDN.

How do I automatically compact and repair an Access 2007 database?

I have a site that uses classic ASP and a database in Access 2007 format (.accdb). It is encrypted with a password and is about 300 MiB in file size.
The site works fine by itself but every now and then the database gets corrupted (the error is "unrecognized database format"). It can be fixed easily by opening the database in MS Access, then it will be repaired. Problem is it can take days before I notice the database is corrupted and during that time the site will be useless. Sometimes it takes months between each corruption, other times only a week or two.
What I want is the site to be able to call the "Compact and Repair Database" function itself every now and then (once a day or so) to keep the database in a working condition.
My question is how do I do this, make it repair itself?
I found this article: How do I compact and repair an ACCESS 2007 database by .NET code?
...but I don't understand how I can make that work for me. I only know classic ASP and Java.
Can anyone write a little isolated ASP code that does this: "open connection to password-protected database", "repairs the database", "close the connection".
The site and database is on a dedicated server which I have full control over so I can implement any solution that exists.
Thank you very much!
You can write a script that repairs the database every now and then. But there are two problems:
1) How to detect the database is corrupt
2) How to minimize data loss.
The biggest problem is that you are trying to fix a problem which lies within the access database itself (frequent data corruption). Because of this, the product is not suitable for any serious application. So why don't you switch to a more reliable database? (MS SQL, MYSQL, ORACLE, SQL Lite, and more to choose from).
Can SQL Server Express be legally licensed for use on a web server? If so then I'd suggest moving your data to it instead. If not there are other options mentioned elsewhere. At the following page SQL Server 2008 Express I see mention of a Web Platform Installer so that would imploy you can use it on a web server. But I do not interpret EULAs so I leave that decision to you.
I got the answer I needed in another question I asked:
Why can't I use "CompactDatabase" in DAO.DBEngine.36 using VBscript?
The user "HansUp" gave me the following code:
Dim objFSO
Dim objEngine
Dim strLckFile
Dim strSrcName
Dim strDstName
Dim strPassword
strLckFile = "C:\Access\webforums\foo.laccdb"
strSrcName = "C:\Access\webforums\foo.accdb"
strDstName = "C:\Access\webforums\compacted.accdb"
strBackup = "C:\Access\webforums\foobackup.accdb"
strPassword = "foo"
Set objEngine = CreateObject("DAO.DBEngine.120")
Set objFSO = CreateObject("Scripting.FileSystemObject")
If Not (objFSO.FileExists(strLckFile)) Then
If (objFSO.FileExists(strBackup)) Then
objFSO.DeleteFile strBackup
End If
If (objFSO.FileExists(strDstName)) Then
objFSO.DeleteFile strDstName
End If
objFSO.CopyFile strSrcName, strBackup
''dbVersion120 = 128
objEngine.CompactDatabase strSrcName, strDstName, , 128, ";pwd=" & strPassword
objFSO.DeleteFile strSrcName
objFSO.MoveFile strDstName, strSrcName
End If 'LckFile
(The code got a few extra line breaks when I copied it for some reason, follow the link at the beginning of this post for a little cleaner version of the code if you wish.)
It compresses a Access 2007 database to a Access 2007 database (no format change) AND it also repairs any corruption (inconsistent state) in the database! Just what I was looking for. =)

Resources