Classic ASP global.asa SQL Server 2008 connection string - sql-server-2008

I have been given a web application written in Classic ASP to port from Windows 2003 Server (SQL Server 2000 and IIS 6) to Windows 2008 Server (SQL Server 2008 and IIS 7.5).
The site uses a GLOBAL.ASA file to define global variables, one of which is the connection string (cnn) to connect to SQL Server.
Below is the (old) connection string from GLOBAL.ASA:
Sub Application_OnStart
Dim cnnDem, cnnString
Set cnnDem = Server.CreateObject("ADODB.Connection")
cnnDem.CommandTimeout = 60
cnnDem.Mode = admodeshareexclusive
cnnString = "Provider=SQLOLEDB; Data Source=192.xxx.x.xx; User Id=xxxx; Password=xxxxx; default catalog=xxxxxxx;"
Application("conString")=cnnString
Call cnnDem.Open(cnnString)
Application("cnn") = cnnDem
End Sub
The .ASP pages then use the cnn value like this:
strSQL = "Select * From tblUtilities order by companyname"
Set rs = Server.CreateObject("ADODB.Recordset")
rs.Open strSQL, Application("cnn"), adOpenKeyset
However I could not get the connection string to connect – I whittled it down to a “Failed to Login” error message (no matter what Login ID I tried).
I edited the GLOBAL.ASA file as follows and it works.
Sub Application_OnStart
Dim cnnDem, cnnString
Set cnnDem = Server.CreateObject("ADODB.Connection")
cnnDem.CommandTimeout = 60
cnnString = "Provider=SQLNCLI10.1;User Id=xxxx; Password=xxxxx;Initial Catalog=xxxxxxx;Data Source=xxxxxx\SQLEXPRESS;"
Application("conString")=cnnString
Application("cnn")=cnnString
Call cnnDem.Open(cnnString)
End Sub
The main difference is that cnn now contains the connection string, where as previously cnn was an object referring to ADOBD.Connection.
The question I have is what impact (if any) will this have on the application. I have done some basic (local) testing and everything looks ok at the moment. But I am wondering if there might be multi-user issues (or something of that nature) that might arise when this site is deployed again.

One of the best and easiest way to connect to create a Database Connection String is to crease a new ASP file in the root directory or elsewhere and include the Connection string into it:
//Global.asp //
<%
Dim connectionString
connectionString = "PROVIDER=SQLOLEDB;DATA SOURCE=YourSQLServer;UID=sa;PWD=*******;DATABASE=YourDataBase"
%>
Then create an include statement in each file that you would like to call this connection.
<!-- #include virtual="global.asp" -->
Then, where you need to setup your connection call, simply use your code to connect to the Database:
<%
Set adoCon = Server.CreateObject("ADODB.Connection")
adoCon.Open = ConnectionString
Set rsReports = Server.CreateObject("ADODB.Recordset")
strSQL = "Select * From Customers"
rsReports.Open strSQL, adoCon
%>

I keep the Connection String in Global.asa but create the connection in a separate function loaded as needed. An Application connection object may not be aware of temporary network issues that may close that connection, and then future attempts to use the connection will not be successful.
Hope this makes sense.

Related

ODBC connection string to Snowflake for Access Pass Thru Query

I am trying to create a connection string to get to Snowflake data from Access 2010 and above. I can create a database DSN and link to the tables I use, but I need to build DSN-less connection strings for distributed applications. Here's what I have so far, it fails with the message "ODBC connection to xxxx failed". Here's what I have so far:
ODBC;Driver={SnowflakeDSIIDriver}; Server=https://server name; Role=role name;Warehouse=warehouse name;Database=db name;Schema=schema name;UID=snowflake ID; PWD=snowflake password;
I think you are on the right track. I have the same thing and it works.
ODBC;
driver={SnowflakeDSIIDriver};
server=accountname.snowflakecomputing.com;database=dbname;
schema=public;
warehouse=whname;
role=rlname;
Uid=userid;
Pwd=password;
Very odd that the DSN one works and your doesn't.
I can confirm that DNS-free connections work fine in Access 2013. I have not tested on Access 2010, but I have it available if that needs testing.
The first problem I encountered is that the Snowflake ODBC driver reports 32/64-bit in the ODBC section of Control Panel, but it may not have one or the other installed.
In my case, it showed in the DSN sources as 32/64-bit, but I had only the 64-bit version installed. Notice that after installing the 32-bit driver, the Programs and Features (where to go normally for uninstalling apps) shows both the 64 and 32 bit drivers.
After installing the 32-bit driver, it was just a matter of getting the connection string right. You want to copy it from the URL on your Snowflake web UI. Strip off the https:// part, and then keep everything up to and including the snowflakecomputing.com in the url. That's what you'll use for the server.
Edit 2: I missed the part of the question that referenced pass through queries and was describing a procedure I tested recently for DNS-free connection using VBA. I tested the pass-through connection and it worked fine. The only difference is in the ODBC connection string you need to keep the "ODBC;" prefix:
ODBC;Driver{SnowflakeDSIIDriver};server=<your_URL_everything_before_snowflakecomputing.com>.snowflakecomputing.com;uid=greg;pwd=xxxxxx
Edit: One thing I forgot and am adding... The built-in Access data engine did not work for me to connect with a DNS-free connection. The code shows that it's using ActiveX Data Objects (ADO). You need to add a reference to that in your VBA project:
' For the account, use everything after https:// up to and including
' snowflakecomputing.com in your URL when connecting to Snowflake using the web UI.
Const SNOWFLAKE_ACCOUNT = "<your_account>.<your_region>.snowflakecomputing.com"
Const SNOWFLAKE_USER = "greg"
Const SNOWFLAKE_PASSWORD = "xxxxx"
Public Sub Main()
Dim odbc As String
Dim sfCon As ADODB.Connection
Set sfCon = OpenDatabaseConnection(GetConnectionString())
If Not sfCon Is Nothing Then
'Use the connection here...
sfCon.Close
End If
End Sub
Private Function GetConnectionString()
GetConnectionString = "Driver={SnowflakeDSIIDriver}" + _
";server=" + SNOWFLAKE_ACCOUNT + _
";uid=" + SNOWFLAKE_USER + _
";pwd=" + SNOWFLAKE_PASSWORD + _
";network_timeout=60" + _
"login_timeout=60"
End Function
Public Function OpenDatabaseConnection(ConnString As String) As ADODB.Connection
On Error GoTo Handler
Dim database As ADODB.Connection
Set database = New ADODB.Connection
With database
.ConnectionString = ConnString
.ConnectionTimeout = 60
.Open
End With
Set OpenDatabaseConnection = database
Exit Function
Handler:
MsgBox "Error: " + Err.Description
End Function

VB.NET MySQL Connection (DB not local)

I'm trying to connect to a MySQL server via VB.NET, but my program keeps freezing on the con.Open() line.
Imports System.Data.SqlClient
Imports System.Data
....
Dim con As New SqlConnection
Dim cmd As New SqlCommand
Try
con.ConnectionString = "Server=000.000.000.000;Database=db_name;Uid=db_user;Pwd=db_pw;"
con.Open()
cmd.Connection = con
cmd.CommandText = "SELECT * FROM courses"
Dim lrd As SqlDataReader = cmd.ExecuteReader()
While lrd.Read()
MessageBox.Show(lrd.ToString)
End While
Catch ex As Exception
MessageBox.Show("Error while connecting to SQL Server: " & ex.Message)
Finally
con.Close()
End Try
The stuff in the connection string is the form of what I have in those spots, using those words as actual value placeholders for this example. Apart from containing the actual values, they are exactly identical. So if there are form errors (i.e. a missing apostrophe), please let me know. For the Server, am I supposed to put the IP address of the server or something else? Furthermore, in the reading loop, I'm not sure how to display all of the contents of the SQL query. Is what I have correct?
You are using ADO.NET for SQL Server instead of what you should be using, an ADO.NET client that works with MySQL, like MySQL Connector
You will need to install this and change SqlClient, SqlCommand, SqlConnection in your code to MySqlClient, MySqlCommand, MySqlConnection in accordance with how the MySQL Connector works.
To display first column values:
While lrd.Read()
MessageBox.Show(lrd.GetValue(0))
End While

Combine rights from 2 SQL-users

Is it anyhow possible to merge 2 SQL logins, so that I can access 2 databases with different logins at the same server?
I'm using ASP Classic (ADODB) and SQL Server 2008
If you want to use two different sets of credentials you'll need to use two connection objects (or constantly close and reopen one).
Eg:
<%
dim dbA, dbB
Set dbA = server.createobject("adodb.connection")
Set dbB = server.createobject("adodb.connection")
Set rs = server.createobject("adodb.recordset")
dbA.open "ConnectionStringForYourFirstDatabase"
dbB.open "ConnectionStringForYourSecondDatabase"
'#### Execute something to database 1 using connection string 1
set rs = dbA.execute("")
'#### Execute something to database 2 using connection string 2
set rs = dbB.execute("")
'#### Tidy Up
set dbA = nothing
set dbB = nothing
%>

Trouble resetting connection string in Access 2010

New to Access 2010. The following VBA code when run doesn't reset the connection string as expected. I'm pretty sure this used to work. What's wrong?
CurrentDb.TableDefs("AccountNumber").Connect = "ODBC;Description=NativeClient;DRIVER=SQL Native Client;SERVER=server1;DATABASE=Expense;Trusted_Connection=Yes"
CurrentDb.TableDefs("AccountNumber").RefreshLink
I am not sure about that connection string. Which version of SQL Server are you using? You might like to try a connection string from http://www.connectionstrings.com/sql-server-2008#p3, for example, this works for me.
scn = "Driver={SQL Server Native Client 10.0};" & _
"Server=ServerName; Database=test;Trusted_Connection=yes;"
With CurrentDb
.TableDefs(sLocalName).Connect = scn
.TableDefs(sLocalName).RefreshLink
End with

Configure Enterprise Library in code

Is it possible to configure the Data Application Block in Enterprise Library entirely in code?
Instead of having the big messy config file.
Ok, after a bit of googeling and some trial and error I've come up with this solution that works pretty good. It uses the System.Data.SQLClient provider.
Just supply a connectionstring:
Dim databaseSettings As Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings
Dim connStringSection As System.Configuration.ConnectionStringsSection = New System.Configuration.ConnectionStringsSection()
Dim dictDataSource As Microsoft.Practices.EnterpriseLibrary.Common.Configuration.DictionaryConfigurationSource
Dim dbProvider As Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DbProviderMapping
Dim dbFactory As DatabaseProviderFactory
Dim database As Microsoft.Practices.EnterpriseLibrary.Data.Database
databaseSettings = New Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings()
connStringSection = New System.Configuration.ConnectionStringsSection()
dictDataSource = New Microsoft.Practices.EnterpriseLibrary.Common.Configuration.DictionaryConfigurationSource()
dbProvider = New Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DbProviderMapping(Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DbProviderMapping.DefaultSqlProviderName, GetType(Sql.SqlDatabase))
connStringSection.ConnectionStrings.Add(New System.Configuration.ConnectionStringSettings("DBConnectionString", connectionString, "System.Data.SqlClient"))
databaseSettings.ProviderMappings.Add(dbProvider)
databaseSettings.DefaultDatabase = "DBConnectionString"
'Add Database Settings to Dictionary
dictDataSource.Add(Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings.SectionName, databaseSettings)
'Add Connection String to Dictionary
dictDataSource.Add("connectionStrings", connStringSection)
dbFactory = New DatabaseProviderFactory(dictDataSource)
database = dbFactory.Create("DBConnectionString")
database.CreateConnection()
Return database
short answer: yes.
Long answer: Why would you want to do that? The whole idea of the "big messy" file is that you write somewhat generic code that uses interfaces and then configure the specifics. Want to switch from ORacle to SQL Server? I've done it just by updating a config variable. Yes it's a bear porting stored procs, but it works.