I recently started working with Visual Studios and to get some practice with its conventions, I'm trying to design a simple application that connects to a database file - in this case, just the Northwind.accdb sample that came along Microsoft Access - and transfers some selected information to an XML file.
I have the bulwark of the code written out to perform the task, but whenever I try to execute it, the program throws some exception that reads, "Could not find installable ISAM." I researched this error for quite a while, and after downloading the MS Access redistributable to no avail, I'm almost sure the problem lies with my connection string:
strDataPath = My.Computer.FileSystem.GetParentPath("Northwind.accdb")
strConnection = "Provider=Microsoft.ACE.OLEDB.12.0;" & _
"Driver={Microsoft Access Driver (*.mdb, *.accdb)}; Data Source=" + strDataPath + ";Persist Security Info=False;"
I've tried writing this out maybe a dozen different ways with all sorts of different attributes, but no matter what I try I always end up with the same error message(even though it compiles just fine). What syntax do I need to get this connection string working? Or could there be another source of error somewher ein my code?
Try this:
strConnection = "Provider=Microsoft.ACE.OLEDB.12.0; Data Source=" + strDataPath + ";Persist Security Info=False;"
The Driver portion of your connection string is used in ODBC connection strings. Don't need it in OleDB connection strings.
Related
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).
Background
i have legacy VB6 code that accesses SQL Server. it produces an error code 0x80004005 when TLS 1.0 is disabled for SQL Server, because the code still uses the provider SQLOLEDB:
[DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security
error.
it does not explicitly use TLS, but TLS is always used for credentials according to Microsoft documentation.
Possible Solution
after looking around i have found that Microsoft released the new provider MSOLEDBSQL as a replacement for SQLOLEDB. MSOLEDBSQL supports TLS 1.2 and that will be kept updated, according to their documentation:
https://learn.microsoft.com/en-us/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-server-ver15
https://learn.microsoft.com/en-us/archive/blogs/sqlnativeclient/released-microsoft-ole-db-driver-for-sql-server
i've tested MSOLEDBSQL after installing the drivers, and changing the (ADODB.Connection) connection string from:
c.ConnectionString = "Provider=SQLOLEDB;Data Source=" & svr & ";Initial Catalog=" & db & ";User Id=" & u & ";Password=" & p & ";"
to:
c.ConnectionString = "Provider=MSOLEDBSQL;DataTypeCompatibility=80;Data Source=" & svr & ";Initial Catalog=" & db & ";User Id=" & u & ";Password=" & p & ";"
and this fixes the problem.
Questions
however, i'm not sure, that what i'm doing is futureproof.
is this the provider MSOLEDBSQL indeed future proof, or would you
recommend another one?
should my VB6 project keep referencing ADODB ("msado28.tlb" Microsoft ActiveX Data Objects 2.8 Library), or is there a more
futureproof reference?
for example: would this work with TLS 1.3 in the future?
i would prefer to change as little as possible
MDAC and the VB6 runtime are Windows components, and MSOLEDBSQL is current, and will continue to be maintained. So that is your best combination for running this legacy codebase now and in the future.
Future proofing is a bit of a "Crystal Ball" kind of thing. There's lots we can do in code to make our lives easier, but at the end of the day - when we're using 3rd party libraries - we don't know when a library will be deprecated, what it will support or unsupport.
When it comes to code that we own as developers, we can write abstractions and do our best to be able to be backwards compatible when we suddenly realise there's a better way of doing things (or, in fact, just doing a code-refactor and don't want to break our clients).
With third-party code, this is not practical. At the end of the day, your database connectivity requires a connection string and a provider that supports it. Expect that can possibly change in the future, and your roadmap should be to keep an eye on it. At some point, you'll have to perform an update, as you just have done.
You might consider refactoring the code responsible for establishing the DB connection into its own VB6 DLL. This DLL would manage the connection string, contain the essential references, and would be responsible for establishing the actual connection and returning the correct object.
Set this DLL up with binary compatibility.
In the future should the connection details change, only this single DLL would need to be affected, minimizing retesting & re-deployment.
In addition you could store data like the connection string in a configuration file. In the limited case where only that text would need to be changed, conceivably a user could do that themselves given good instructions. But otherwise I don't think the added complexity of a config file would be worth it; it also creates more pitfalls and points of failure.
I'm working on a legacy visual basic application that uses a Jet.OLEDB.4.0 connection string. The user wants to move the application's database (an .mdb file) to a networked location. I was able to allow the user to set the new data file location and everything works, only it is very slow compared to when the db is on the local machine. Microsoft suggests changing the PageTimeout property in the connection string (http://support.microsoft.com/kb/246560/EN-US) and that's where I'm running into issues. Below is the connection string that works but is slow:
Public connStr As String = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & My.Settings.DataFolderPath & "\Data.mdb;Persist Security Info=True;Jet OLEDB:Database Password=Password;"
When I try to add the PageTimeOut property I get a "Could not find installable ISAM." error from Visual Studio. I'm sure I'm missing something really simple here, and this may not even fix the slow network performance. Here is the connection string that is throwing the error:
Public connStr As String = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & My.Settings.DataFolderPath & "\Data.mdb;Persist Security Info=True;Jet OLEDB:Database Password=Password;PageTimeout=5000"
I also tried
Public connStr As String = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & My.Settings.DataFolderPath & "\Data.mdb;Persist Security Info=True;Jet OLEDB:Database Password=Password;Jet OLEDB:PageTimeout=5000"
Any help you could provide would be greatly appreciated.
The spelling is different:
Jet OLEDB:Page Timeout // note the space
Full documentation here:
Jet OLEDB:Page Timeout (DBPROP_JETOLEDB_PAGETIMEOUT)
Indicates the number of milliseconds Jet will wait before checking to see whether its cache is out of date with the database file.
Nevertheless, the value cannot be set in a connection string at all, as KB 318161 explains:
The Microsoft OLE DB Provider for Jet includes many custom properties
that you can set only after you establish a connection to the
database. These provider-specific properties are custom OLE DB session
properties. You cannot set these properties in the ADO OLE DB
connection string; you must set these properties after the connection
is opened.
This error occurs when you specify the following Jet-specific
properties in the connection string:
Jet OLEDB:ODBC Command Time Out
Jet OLEDB:Max Locks Per File
Jet OLEDB:Implicit Commit Sync
Jet OLEDB:Flush Transaction Timeout
Jet OLEDB:Lock Delay
Jet OLEDB:Max Buffer Size
Jet OLEDB:User Commit Sync
Jet OLEDB:Lock Retry
Jet OLEDB:Exclusive Async Delay
Jet OLEDB:Shared Async Delay
Jet OLEDB:Page Timeout
Jet OLEDB:Recycle Long-Valued Pages
Jet OLEDB:Reset ISAM Stats
Jet OLEDB:Connection Control
Jet OLEDB:ODBC Parsing
Jet OLEDB:Page Locks to Table Lock
Jet OLEDB:Sandbox Mode
Jet OLEDB:Transaction Commit Mode
This is probably not a solution to your problem, but as a potential quick-fix, have you tried using a DSN? Once you set it up in Windows ODBC, you can alter your connection string to look like this:
"DSN=MyDSN;PageTimeout=5000;"
Again, this is probably not a solution, but it might be a quick-fix to get you moving in the meanwhile.
I'm trying to get this open source code to work in order to start building the basics for my own program. The general idea was just to create a small application that can access and manipulate SQL records, simple, right? Turns out I can't event get the testing going. I keep getting an error on runtime/debug.
The error:
An unhandled exception of type 'System.Data.SqlClient.SqlException'
occurred in System.Data.dll
Additional information: A network-related or instance-specific error
occurred while establishing a connection to SQL Server. The server was
not found or was not accessible. Verify that the instance name is
correct and that SQL Server is configured to allow remote connections.
(provider: Named Pipes Provider, error: 40 - Could not open a
connection to SQL Server)
Here's the code that's not working
Module modConn
Public connDB As New SqlClient.SqlConnection
Public comDB As New SqlClient.SqlCommand
Public rdDB As SqlClient.SqlDataReader
Public Item As ListViewItem
Public SQL As String
Public Sub conecDB()
Dim strServer As String = "127.0.0.1" 'This is the server IP/Server name.
Dim strDbase As String = "Members_Details" 'Database name
Dim strUser As String = "CENSORED" 'Database user
Dim strPass As String = "CENSORED" 'Database password
If connDB.State <> ConnectionState.Open Then connDB.ConnectionString = "Server=" & strServer.Trim & ";Database=" & strDbase.Trim & ";User ID=" & strUser.Trim & ";Password=" & strPass
If connDB.State <> ConnectionState.Open Then connDB.Open
End Sub
The error is referring to the last line connDB.Open.
I've verified the SQL server is running. It's accepting all protocols (TCP/IP, Named Pipes & Shared Memory). The server is MS Server Express + SQL Server Management Studio... And I'm able to sign in and manipulate the database using the SQL Server Managment Studio by using the same login credentials as the program, so I'm pretty sure it's the programs code that's wrong.
My guess is that the area of the code that it brings everything together is wrong; perhaps a character or something -- I'm referring to
If connDB.State <> ConnectionState.Open Then connDB.ConnectionString = "Server=" & strServer.Trim & ";Database=" & strDbase.Trim & ";User ID=" & strUser.Trim & ";Password=" & strPass
If connDB.State <> ConnectionState.Open Then connDB.Open
Any help would be greatly appreciated. I'm relatively new to programming and this is more of a challenge then anything else. Please, in your replies try to keep it structures similarly to what I've got already, if you can.
I'm using Visual Basic Studio on .net 4.5. Thanks in advance!
thanks for your usual fast replies. I've managed to work a solution out when I decided to dig deeper into Mitch Wheat's recommendation to verify the configuration of the SQL Server. It turns out the issue was with the SQL Server configuration. This excellent site had a solution to that as well, thanks! Much appreciated!
The solution to me problem was this. (Link)
I had a deployed visual project 2010 connected to sql and I had installed it in another computer but the database can't connect to the final project. I want to install it in other computers that will be connected to database. I think I have a problem in my connection:
Dim con As SqlConnection = New SqlConnection("Data Source=localhost;Integrated Security=SSPI;" & _
"Initial Catalog=enrollment")
The information provided at this link will provide you with a good idea of how to manage connection strings in VS. The problem with your SqlConnection object is that your data source is still listed as 'localhost'. You need to change this to point to the location of your database.
Ideally the application should have a user friendly way of specifiying the settings for the connection, this will make connecting from different locations far easier and makes your application more portable.
I think this example here will help you