connections not closed by app

we inherited this java web app that uses a jdbc-odbc bridge for connecting
to 2 sql server 2000 instances. there are probably hundreds of places in
the application where connections are not being closed (resultsets and
statements not being closed as well).
my question:
1) i assume that as DBAs you would all frown on this? do you have
suggestions about doing something on the db side to address this?
2) what i though was something like: does sql server automatically (or can
i make it) close connections after a peroid of time? would that work?Dont know that I would actually do this, but if all else fails:
1; sp_who2 into a temp table
2; have a cursor loop through the LastBatch column, using dynamic sql, and
KILL everything > 5 minutes. (Or whatever time you decide on.)
I would really try to exhaust all other resources before using this method,
just an idea to keep in mind in case you get this deperate.
--
TIA,
ChrisR
"usenetjb" wrote:
> we inherited this java web app that uses a jdbc-odbc bridge for connecting
> to 2 sql server 2000 instances. there are probably hundreds of places in
> the application where connections are not being closed (resultsets and
> statements not being closed as well).
> my question:
> 1) i assume that as DBAs you would all frown on this? do you have
> suggestions about doing something on the db side to address this?
> 2) what i though was something like: does sql server automatically (or can
> i make it) close connections after a peroid of time? would that work?
>|||Wow. The program must be fixed but for now, I would consider setting up a
schedule to reboot the server at night.
"usenetjb" <usenet.20.jimbo-black@.antichef.net> wrote in message
news:Xns97335385B8126usenetjb@.207.115.17.102...
> we inherited this java web app that uses a jdbc-odbc bridge for connecting
> to 2 sql server 2000 instances. there are probably hundreds of places in
> the application where connections are not being closed (resultsets and
> statements not being closed as well).
> my question:
> 1) i assume that as DBAs you would all frown on this? do you have
> suggestions about doing something on the db side to address this?
> 2) what i though was something like: does sql server automatically (or can
> i make it) close connections after a peroid of time? would that work?|||"Grant" <email@.nowhere.com> wrote in
news:uUcMfmzBGHA.3572@.TK2MSFTNGP14.phx.gbl:
> Wow. The program must be fixed but for now, I would consider setting
> up a schedule to reboot the server at night.
>
>
wow is not what i said, but then again ... believe it or not the app has
to be up 24/7. so we generally reboot the box after a week to make the app
speed up, sigh. it is leaking resources all over the place on the java app
side.
anyway, can sql server reboot itself? do you have any suggestions in terms
of tools to automate this sql server reboot?
thx

connections not closed by app

we inherited this Java web app that uses a jdbc-odbc bridge for connecting
to 2 sql server 2000 instances. there are probably hundreds of places in
the application where connections are not being closed (resultsets and
statements not being closed as well).
my question:
1) i assume that as DBAs you would all frown on this? do you have
suggestions about doing something on the db side to address this?
2) what i though was something like: does sql server automatically (or can
i make it) close connections after a peroid of time? would that work?Dont know that I would actually do this, but if all else fails:
1; sp_who2 into a temp table
2; have a cursor loop through the LastBatch column, using dynamic sql, and
KILL everything > 5 minutes. (Or whatever time you decide on.)
I would really try to exhaust all other resources before using this method,
just an idea to keep in mind in case you get this deperate.
TIA,
ChrisR
"usenetjb" wrote:

> we inherited this Java web app that uses a jdbc-odbc bridge for connecting
> to 2 sql server 2000 instances. there are probably hundreds of places in
> the application where connections are not being closed (resultsets and
> statements not being closed as well).
> my question:
> 1) i assume that as DBAs you would all frown on this? do you have
> suggestions about doing something on the db side to address this?
> 2) what i though was something like: does sql server automatically (or can
> i make it) close connections after a peroid of time? would that work?
>|||Wow. The program must be fixed but for now, I would consider setting up a
schedule to reboot the server at night.
"usenetjb" <usenet.20.jimbo-black@.antichef.net> wrote in message
news:Xns97335385B8126usenetjb@.207.115.17.102...
> we inherited this Java web app that uses a jdbc-odbc bridge for connecting
> to 2 sql server 2000 instances. there are probably hundreds of places in
> the application where connections are not being closed (resultsets and
> statements not being closed as well).
> my question:
> 1) i assume that as DBAs you would all frown on this? do you have
> suggestions about doing something on the db side to address this?
> 2) what i though was something like: does sql server automatically (or can
> i make it) close connections after a peroid of time? would that work?|||"Grant" <email@.nowhere.com> wrote in
news:uUcMfmzBGHA.3572@.TK2MSFTNGP14.phx.gbl:

> Wow. The program must be fixed but for now, I would consider setting
> up a schedule to reboot the server at night.
>
>
wow is not what i said, but then again ... believe it or not the app has
to be up 24/7. so we generally reboot the box after a week to make the app
speed up, sigh. it is leaking resources all over the place on the Java app
side.
anyway, can sql server reboot itself? do you have any suggestions in terms
of tools to automate this sql server reboot?
thx

connections not closed by app

we inherited this java web app that uses a jdbc-odbc bridge for connecting
to 2 sql server 2000 instances. there are probably hundreds of places in
the application where connections are not being closed (resultsets and
statements not being closed as well).
my question:
1) i assume that as DBAs you would all frown on this? do you have
suggestions about doing something on the db side to address this?
2) what i though was something like: does sql server automatically (or can
i make it) close connections after a peroid of time? would that work?
Dont know that I would actually do this, but if all else fails:
1; sp_who2 into a temp table
2; have a cursor loop through the LastBatch column, using dynamic sql, and
KILL everything > 5 minutes. (Or whatever time you decide on.)
I would really try to exhaust all other resources before using this method,
just an idea to keep in mind in case you get this deperate.
TIA,
ChrisR
"usenetjb" wrote:

> we inherited this java web app that uses a jdbc-odbc bridge for connecting
> to 2 sql server 2000 instances. there are probably hundreds of places in
> the application where connections are not being closed (resultsets and
> statements not being closed as well).
> my question:
> 1) i assume that as DBAs you would all frown on this? do you have
> suggestions about doing something on the db side to address this?
> 2) what i though was something like: does sql server automatically (or can
> i make it) close connections after a peroid of time? would that work?
>
|||Wow. The program must be fixed but for now, I would consider setting up a
schedule to reboot the server at night.
"usenetjb" <usenet.20.jimbo-black@.antichef.net> wrote in message
news:Xns97335385B8126usenetjb@.207.115.17.102...
> we inherited this java web app that uses a jdbc-odbc bridge for connecting
> to 2 sql server 2000 instances. there are probably hundreds of places in
> the application where connections are not being closed (resultsets and
> statements not being closed as well).
> my question:
> 1) i assume that as DBAs you would all frown on this? do you have
> suggestions about doing something on the db side to address this?
> 2) what i though was something like: does sql server automatically (or can
> i make it) close connections after a peroid of time? would that work?
|||"Grant" <email@.nowhere.com> wrote in
news:uUcMfmzBGHA.3572@.TK2MSFTNGP14.phx.gbl:

> Wow. The program must be fixed but for now, I would consider setting
> up a schedule to reboot the server at night.
>
>
wow is not what i said, but then again ... believe it or not the app has
to be up 24/7. so we generally reboot the box after a week to make the app
speed up, sigh. it is leaking resources all over the place on the java app
side.
anyway, can sql server reboot itself? do you have any suggestions in terms
of tools to automate this sql server reboot?
thx

connection to SQL Server files (*.mdf) require SQL server express 2005 to function properl

I dont have the SQL EXPRESS installed instead I have SQL Standard Edition.

I have two SQL Server instances installed.

1- UserLT (this is sql 2000)
2- UserLT\SQL2005 (this is SQL 2005 named instance)

But when i try to add a database to my VS website project I get the following error:

Connection to SQL Server files (*.mdf) require SQL server express 2005 to function properly. please verify the installation of the component or download from the URL: go.microsoft.com/fwlink/?linkId=4925

I went in Tools>Opetions>DataBase tools>Data Connection>Sql Server Instance Name (blank for default)

and changed the "SQLEXPRESS" to "USERLT\SQL2005".

But I still get the same error message. Any ideas how i can resolve this issue?

Hello,

Attach the files to your SQL server instance using for example the SQL management Studio and change your connectionstring to connect into this database.

|||

Well the thing is that I dont have a database created yet. I am trying to create a new database. If i create a database in SQL 2005 then my connectionstring will point to the database on sql server. I need the database to reside in the VS project like a stand alone .mdf file so that I can deply the database with my project.

Does that make sense? Thanks for your help.

|||

Hi,

You may open your Machine.Config file (the file is in %SystemRoot%\Microsoft.NET\Framework\ver. number\CONFIG ). Try to find the ConnectionString node, modify the setting and make it look like

<add name="LocalSqlServer" connectionString="data source=UserLT\SQL2005;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true" providerName="System.Data.SqlClient" />

Thanks.

Connection string for default instance of SQL Server 2005, on a box also running a named i

The box I am trying to connect to is running two instances of SQL Server.

There is a SQL Server 2005 instance which is the default. There is a SQL Server 2000 instance which is named 'SQLSERVER'.

I can connect to the SQL Server 2000 instance no problem:

<addkey="ConnectionString"value="server=MYPC\SQLSERVER;database=mydatabase;user id=****;password=****"/>

However, I am having trouble connecting to the Default SQL Server 2005 instance. I have tried:

<addkey="ConnectionString"value="server=MYPC;database=mydatabase;user id=****;password=****"/>

but it doesn't work. I have tried explicitly setting SQL Server 2005 to use port 1434 (as SQL Server 2000 is running on port 1433), and then used:

<addkey="ConnectionString"value="server=MYPC,1434;database=mydatabase;user id=****;password=****"/>

but this doesn't work either.

Am I mssing something here? Any help much appreciated

Thanks...

Since both SQL Server 2000 and 2005 are running on the same machine, definitely one of the instance will be the named instance.

I guess SQL 2005 is a named instance. So the connection should be as follows:

server=MYPC\<Instance name>;database=mydatabase;user id=****;password=****

|||

Hi, thanks for the reply.

No, SQL Server 2000 was the named instance. SQL Server 2005 was the default. It was the default instance (SQL Server 2005) that I was having problems connecting to. Ineed, I was having trouble connecting to it with anything other than Enterprise Manager.

However, I have uninstalled / reinstalled SQL Server 2000 and SQL Server 2005, and made them both named instances. I can now connect to them both no problem.

I suspect that had I reinstalled with one or other of them being a default instance, I also would have had no problems. I had noticed a number of other strange behavioural issues in SQL Server 2005 and I suspect something had gone awry in general.