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.
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).
I have a big Problem sending an SQL-Dump made with SQL-Server Management Studio via vb.net to another SQL-Server.
I made the SQL-Files like this: Database / Tasks / scripts ...
After deleting every "GO" command in the Dump I managed to upload to my local SQL-Server 2012. But this worked only if I made different scripts for any table.
If I use one big File, I get a timeout.
Now I want to transfer the Data (50 MB) to another SQL Server via Internet connection.
Only 3 of 5 Tables are generated on this server :-(
I get the following timeout error (german version, sorry):
"Eine Ausnahme (erste Chance) des Typs "System.Data.SqlClient.SqlException" ist in System.Data.dll aufgetreten.
Timeout abgelaufen. Das Zeitlimit wurde vor dem Beenden des Vorgangs überschritten oder der Server reagiert nicht."
Any Idea which side makes the timeout (SQL-Server oder vb.net)?
Is there a safer method uploading lots of data to a SQL-Server?
This is the code I use (The SQL-Skript is in My.Resources.SQLDump):
'####SQLDump #######
Dim SQLscript As String = My.Resources.SQLDump
SQLscript = "USE [" + TextBoxDB.Text + "] " + vbCrLf + SQLscript
Using connection As New SqlConnection(Verbind.ConStr)
Using command As New SqlCommand()
' Set the connection
command.Connection = connection
' Not necessary, but good practice
command.CommandType = CommandType.Text
' Example query using parameters
command.CommandText = SQLscript
Try
connection.Open()
rowsAffected = command.ExecuteNonQuery()
Catch ex As Exception
Debug.Print(ex.Message)
Finally
command.Dispose()
connection.Dispose()
End Try
'command.ExecuteNonQuery()
End Using ' Dispose Command
End Using ' Dispose (and hence Close) Connection
MsgBox("DB-Upload 1/5 fertig!")
Is there a safer method uploading lots of data to a SQL-Server?
Yes, there are couple of ways to load data into SQL Server
bcp Utility
BULK INSERT statement
OPENROWSET
SQL Server Import and Export Wizard
Important note: On a 64-bit computer, Integration Services installs
the 64-bit version of the SQL Server Import and Export Wizard
(DTSWizard.exe). However, some data sources, such as Access or Excel,
only have a 32-bit provider available. To work with these data
sources, you might have to install and run the 32-bit version of the
wizard. To install the 32-bit version of the wizard, select either
Client Tools or SQL Server Data Tools (SSDT) during setup.
SSIS
Tutorial to create a SSIS package
Being a SSIS developer I can go in deep and demostrate possible ways to import data by using SSIS like
Bulk import
Script task
Flat file source/ Excel source
Etc Etc.. but that would be different from the question which you have asked.
Regarding, resolving your error you can set the command timeout property in your code to make it run for any specific time limit or limitless.
command.CommandTimeout = 1;
Note: The CommandTimeout property will be ignored during asynchronous
method calls such as BeginExecuteReader.
Edited
Here is the sample code
Using command As New SqlCommand()
command.Connection = connection
command.CommandType = CommandType.Text
command.CommandText = SQLscript
command.CommandTimeout = 1
Try
connection.Open()
rowsAffected = command.ExecuteNonQuery()
Catch ex As Exception
Debug.Print(ex.Message)
Finally
command.Dispose()
connection.Dispose()
End Try
End Using
Other way is to extend connection timeout in your connection string. It accept integer which indicates seconds (in below example connection timeout is set to 30 seconds; 0 means unlimited)
Connection Timeout=30;
Import / Export Wizard for one time move
Since you were able to generate scripts, you have access to the source. Since you're able to execute them, you have access to the destination, and you have Management Studio installed. Your fastest option, IMO, is the Import Export utility provided by Sql Server.
In Sql Server Management Studio, right click on the source database name, click on "Tasks" and then click on "Export Data". This opens up a wizard that will let you put in Source, Destination, and pick the objects you want to export.
While 50 MB of scripts is large, 50MB of data move should finish within a matter of minutes.
Moving data over and over again
You have several options, I would go with OpenRowset, especially for the size of data you're moving. Here's a reference https://msdn.microsoft.com/en-us/library/ms190312.aspx
If you go into moving Gigabytes worth of data regularly, then SSIS packages are your best option. Here's a tutorial https://msdn.microsoft.com/en-us/library/ms169917.aspx
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.
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.
This should be painfully simple, but I cannot come up with a working connection string for a local copy of SQL Server 2008 using Windows Authentication. I've tried using the Data Link Properties tool to create a connection string and it has no problems connecting, but when I copy paste the generated string into my ADODB.Connection object's ConnectionString property I get all sorts of fun and different errors.
Set conn = Server.CreateObject("ADODB.Connection")
conn.ConnectionString = "SQLNCLI10.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=climb4acure;Data Source=(local);"
Microsoft OLE DB Service Components (0x80040E21)
Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done.
I've tried a variety of similar connection strings but I cannot find one that will work with Windows Authentication. Can someone point me in the right direction?
Thanks!
Here's an easy way to generate connection strings that work.
Right-click an empty spot on the desktop and choose NEW, TEXT DOCUMENT from the context menu
Save it with a .udl extension, and click yes when it asks are you sure.
Double-click the new udl file you just created. It will open a dialogue. Go to the Provider tab, and choose the appropriate provider.
Go to the Connection tab and fill in the server name and database name, and choose NT authentication (or use a specific username and password, which is SQL authentication). Now click Test Connection. If it works, you're ready to click OK and move on to the final step. If it doesn't you need to resolve permission issues, or you've mis-typed something.
Now right-click the file on the desktop and open it in notepad. It will display the connection string that you can copy and paste to wherever you need it.
I assume you have the 2008 Native Client installed? Also, I noticed that you're missing the "provider" tag at the beginning - do you have any more luck with this one:
Provider=SQLNCLI10.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=climb4acure;Data Source=(local);
Have you had a look at connectionstrings.com? They are a pretty good reference (but, in my experience, they don't work too well in the Google Chrome browser).
Works absolutely fine:
"Provider=SQLNCLI;Server=xxxxxxxx;uid=sa;pwd=xxxxxx;database=xxxxxx;"