October 18, 2018 at 8:48 am
I am working with a developer who has inherited an application which points to an old server (Dev16). The application is written in classis ASP. Now she wants to start using this new DB (AppDev16)which was setup recently. She and I don't know how we can make the application point to this new server since we don't have a web config file. Any idea because I have never worked on changing any connection strings for any application in the past so I don't even know where to start from.
October 18, 2018 at 11:46 am
Chitown - Thursday, October 18, 2018 8:48 AMI am working with a developer who has inherited an application which points to an old server (Dev16). The application is written in classis ASP. Now she wants to start using this new DB (AppDev16)which was setup recently. She and I don't know how we can make the application point to this new server since we don't have a web config file. Any idea because I have never worked on changing any connection strings for any application in the past so I don't even know where to start from.
You'll need to find the connection string used in the application by searching the code used by the application. Try searching for "ADODB.Connection" or "Provider" or even the old server name.
Sue
October 18, 2018 at 12:38 pm
Classic ASP often made use of include files, so as Sue_H suggested, you just need to search the files for the database/server name and zoom in on possible locations to fix.
Lowell
October 18, 2018 at 1:52 pm
Lowell - Thursday, October 18, 2018 12:38 PMClassic ASP often made use of include files, so as Sue_H suggested, you just need to search the files for the database/server name and zoom in on possible locations to fix.
Thanks for jumping in and adding the inc files - totally forgot about those. It seems too long ago for my old brain.
Sue
October 19, 2018 at 11:51 am
Thanks for the reply but the problem is (and trust me, its a really strange situation) that the connection string doesn't have the server name. I think all I saw was the userID, pwd, DB name but no provider, no server name.
"He who learns for the sake of haughtiness, dies ignorant. He who learns only to talk, rather than to act, dies a hyprocite. He who learns for the mere sake of debating, dies irreligious. He who learns only to accumulate wealth, dies an atheist. And he who learns for the sake of action, dies a mystic."[/i]
October 19, 2018 at 12:16 pm
if there is no server name, then it is implied that the database exists on the local server; is that how it was set up originally? if you can find the connection string you can add the server attribute;
Data Source=AppDev16;
a typical connection string might look like this: ConnectionManager cm = Dts.Connections.Add("OLEDB");
cm.ConnectionString = "Data Source=localhost;Initial Catalog=AdventureWorks;Provider=SQLNCLI10;Integrated Security=SSPI;Auto Translate=False;";
Lowell
October 19, 2018 at 1:58 pm
Admintering Databases - Friday, October 19, 2018 11:51 AMThanks for the reply but the problem is (and trust me, its a really strange situation) that the connection string doesn't have the server name. I think all I saw was the userID, pwd, DB name but no provider, no server name.
With Classic ASP, people would stash the connection details in any number of unrelated places, depending on how the app was built and what kind of security was in place.
Is there an Alias defined that is being used (SQL Server Configuration Manager -> SQL Native Client Configuration -> Aliases), something in the app server's hosts file, or DNS tricks?
Is it using a User, System, or File DSN? (open the ODBC Data Source Administrator (32-bit) application and check the DSN tabs)
Is this Classic ASP app using COM+ objects to perform the database work? If so, those COM+ objects have their own settings, which may be where you need to make your change (on the ASP server, open the Component Services application, expand Component Services -> Computers -> My Computer -> COM+ Applications, and review the list of COM+ objects there to see if any of those are custom-built. Generally, 'System Application' and anything with a name that start with 'COM+' are Windows system packages. Anything else in there should be reviewed (right-click a COM+ package and choose Properties). There's always the chance that the connection was hard-coded in the compiled object.
-Eddie
Eddie Wuerch
MCM: SQL
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply