Hello ,
I have an application that uses MSDE internally. Now I want to replace
that MSDE database by full SQL Server 2005. I have SQL server 2005
installed.
Is it possible to replace the MSDE instance that the application is
using, by SQL server instance without changing the application's
configurations?
Thanks,
Anirudh Bakore.
Hi,
You could.. All you have to do is:-
1. back up the databases in MSDE
2. Restore the database in SQL 2005
3. Create the logins
4. Change the application connection string to point to SQL server 2005
Thanks
Hari
"anibakore" <ani.bakore@.gmail.com> wrote in message
news:1162202124.621048.175580@.e3g2000cwe.googlegro ups.com...
> Hello ,
> I have an application that uses MSDE internally. Now I want to replace
> that MSDE database by full SQL Server 2005. I have SQL server 2005
> installed.
> Is it possible to replace the MSDE instance that the application is
> using, by SQL server instance without changing the application's
> configurations?
>
> Thanks,
> Anirudh Bakore.
>
|||That's the main problem.. I dont have an access to the
connectionstring. It is embedded in the application.
Hari Prasad wrote:
[vbcol=seagreen]
> Hi,
> You could.. All you have to do is:-
> 1. back up the databases in MSDE
> 2. Restore the database in SQL 2005
> 3. Create the logins
> 4. Change the application connection string to point to SQL server 2005
> Thanks
> Hari
>
> "anibakore" <ani.bakore@.gmail.com> wrote in message
> news:1162202124.621048.175580@.e3g2000cwe.googlegro ups.com...
|||That may present a bit more of a challenge.
First, it is important to determine if the MSDE is the 'default' instance of
SQL Server, or if it is a 'named instance'.
Go to [Administrative Tools], and select the [Services] applet.
How many services that start with MSSQL do you find?
If more than MSSQLSERVER, what are the names?
Gather and report that information and someone here can help you further.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
You can't help someone get up a hill without getting a little closer to the
top yourself.
- H. Norman Schwarzkopf
"anibakore" <ani.bakore@.gmail.com> wrote in message
news:1162270303.823821.177750@.m73g2000cwd.googlegr oups.com...
> That's the main problem.. I dont have an access to the
> connectionstring. It is embedded in the application.
> Hari Prasad wrote:
>
|||Hi,
The instance is a named instance.There is a separate service called
"MSSQL$Appname".
Where Appname is the name of the application I am using.
Thanks,
Anirudh
Arnie Rowland wrote:
[vbcol=seagreen]
> That may present a bit more of a challenge.
> First, it is important to determine if the MSDE is the 'default' instance of
> SQL Server, or if it is a 'named instance'.
> Go to [Administrative Tools], and select the [Services] applet.
> How many services that start with MSSQL do you find?
> If more than MSSQLSERVER, what are the names?
> Gather and report that information and someone here can help you further.
> --
> Arnie Rowland, Ph.D.
> Westwood Consulting, Inc
> Most good judgment comes from experience.
> Most experience comes from bad judgment.
> - Anonymous
> You can't help someone get up a hill without getting a little closer to the
> top yourself.
> - H. Norman Schwarzkopf
>
> "anibakore" <ani.bakore@.gmail.com> wrote in message
> news:1162270303.823821.177750@.m73g2000cwd.googlegr oups.com...
|||I would recommend that you first install SQL 2005 on a test computer and
test the application against the test server.
This article seems to be complete about the 'in-place' upgrade process.
http://www.microsoft.com/technet/prodtechnol/sql/2005/msde2sqlexpress.mspx
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
You can't help someone get up a hill without getting a little closer to the
top yourself.
- H. Norman Schwarzkopf
"anibakore" <ani.bakore@.gmail.com> wrote in message
news:1162272568.028079.227760@.k70g2000cwa.googlegr oups.com...
> Hi,
> The instance is a named instance.There is a separate service called
> "MSSQL$Appname".
> Where Appname is the name of the application I am using.
> Thanks,
> Anirudh
> Arnie Rowland wrote:
>
Showing posts with label msde. Show all posts
Showing posts with label msde. Show all posts
Friday, March 30, 2012
Wednesday, March 7, 2012
Repair database that grew over 2 GB
Because of a configuration error by field engineer who didn't check the
error logs before leaving, an error logging table in an MSDE database has
made it grow to 2GB in a couple of days.
The result is that the database status became "suspect" (I had to connect
through enterprise manager to see that) and it can no longer be opened.
At the same time, I noticed that the $&*$##% has renamed the computer after
installing MSDE and initializing the database, despite my urging him never
to do so: as a result the backup schedule that's created along with the
database was no longer executed, the last backup dates from last April
instead of a few hours before it stopped working.
Needless to say that the customer is very happy.
Now I think I made an additional error by trying to detach and re-attach
the database: MSDE won't even re-attach it anymore, with an error "the
primary file group is full".
Is there a way to force MSDE to load it anyway so the extraneous data can
be deleted?
Can the file be attached to a full SQL server, the runaway table purged
there, and then re-attached to MSDE?
Sorry, it seems I clicked 'Reply' in stead of 'new post' by mistake.
error logs before leaving, an error logging table in an MSDE database has
made it grow to 2GB in a couple of days.
The result is that the database status became "suspect" (I had to connect
through enterprise manager to see that) and it can no longer be opened.
At the same time, I noticed that the $&*$##% has renamed the computer after
installing MSDE and initializing the database, despite my urging him never
to do so: as a result the backup schedule that's created along with the
database was no longer executed, the last backup dates from last April
instead of a few hours before it stopped working.
Needless to say that the customer is very happy.
Now I think I made an additional error by trying to detach and re-attach
the database: MSDE won't even re-attach it anymore, with an error "the
primary file group is full".
Is there a way to force MSDE to load it anyway so the extraneous data can
be deleted?
Can the file be attached to a full SQL server, the runaway table purged
there, and then re-attached to MSDE?
Sorry, it seems I clicked 'Reply' in stead of 'new post' by mistake.
Repair database that grew over 2 GB
Because of a configuration error by field engineer who didn't check the
error logs before leaving, an error logging table in an MSDE database has
made it grow to 2GB in a couple of days.
The result is that the database status became "suspect" (I had to connect
through enterprise manager to see that) and it can no longer be opened.
At the same time, I noticed that the $&*$##% has renamed the computer after
installing MSDE and initializing the database, despite my urging him never
to do so: as a result the backup schedule that's created along with the
database was no longer executed, the last backup dates from last April
instead of a few hours before it stopped working.
Needless to say that the customer is very happy.
Now I think I made an additional error by trying to detach and re-attach
the database: MSDE won't even re-attach it anymore, with an error "the
primary file group is full".
Is there a way to force MSDE to load it anyway so the extraneous data can
be deleted?
Can the file be attached to a full SQL server, the runaway table purged
there, and then re-attached to MSDE?
On Tue, 28 Dec 2004 12:14:46 +0100, Lucvdv <replace_name@.null.net> wrote:
> Because of a configuration error by field engineer who didn't check the
> error logs before leaving, an error logging table in an MSDE database has
> made it grow to 2GB in a couple of days.
I just tried to recreate the problem on a test machine: the .mdf file grew
to 1869 MB (1.82 GB), then it stopped with "PRIMARY file group full", but
the database remains accessible, only inserts fail.
In the problem case, the .mdf file was slightly over 2 GB (2.03GB or so, I
don't remember exactly.)
Is there an explanation for this?
|||On Tue, 28 Dec 2004 12:14:46 +0100, Lucvdv <replace_name@.null.net> wrote:
> Can the file be attached to a full SQL server, the runaway table purged
> there, and then re-attached to MSDE?
Relief all around: after copying and attaching the database to a full SQL
Server, shrinking it there and then moving it back to MSDE, everything is
up and running again.
|||hi,
"Lucvdv" <replace_name@.null.net> ha scritto nel messaggio
news:ivf2t0ln44sb9r9ll8ucnknidv4pg4ppad@.4ax.com
> ...
> Can the file be attached to a full SQL server, the runaway table
> purged there, and then re-attached to MSDE?
yes... you can get the mdf (+ ndf if present) + ldf database files set,
take them to your office, purge the "extra" data and shrink the database
data file(s) to a size allowed by MSDE..
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||On Tue, 28 Dec 2004 17:12:37 +0100, "Andrea Montanari"
<andrea.sqlDMO@.virgilio.it> wrote:
> hi,
> "Lucvdv" <replace_name@.null.net> ha scritto nel messaggio
> news:ivf2t0ln44sb9r9ll8ucnknidv4pg4ppad@.4ax.com
> yes... you can get the mdf (+ ndf if present) + ldf database files set,
> take them to your office, purge the "extra" data and shrink the database
> data file(s) to a size allowed by MSDE..
Thanks. I had tried and found that it worked shortly before you replied.
I tried to repeat it on a test machine later, but couldn't make the .mdf
grow above 2GB: all inserts started failing when the final file grow step
had to be done. It actually stopped around 1850 MB with % growth steps, it
refused to go closer to 2G until I changed that to 5MB fixed increments,
and then it stopped at 2044 MB.
The database remained usable, I could detach and attach it, only inserts
failed.
Yet in the problem case it was 2.03GB or something like that (slightly
above 2GB anyway), and MSDE refused to use it any further.
Do you have an idea how that might have happened?
I also noticed when I changed the file growth settings from % to fixed
size, that the change didn't take effect until I had detached and
re-attached the database (rebooting or restarting the service would
probably have done it too, what I mean is that inserts didn't start working
again by just changing the setting).
Is that something known?
|||hi Lucvdv,
"Lucvdv" <replace_name@.null.net> ha scritto nel messaggio
news:94r4t0p6bvclndb2l8gjuhogmd9ho8hq00@.4ax.com
> ...
> I tried to repeat it on a test machine later, but couldn't make the
> .mdf grow above 2GB: all inserts started failing when the final file
> grow step had to be done. It actually stopped around 1850 MB with %
> growth steps, it refused to go closer to 2G until I changed that to
> 5MB fixed increments, and then it stopped at 2044 MB.
> The database remained usable, I could detach and attach it, only
> inserts failed.
> Yet in the problem case it was 2.03GB or something like that (slightly
> above 2GB anyway), and MSDE refused to use it any further.
> Do you have an idea how that might have happened?
>
> I also noticed when I changed the file growth settings from % to fixed
> size, that the change didn't take effect until I had detached and
> re-attached the database (rebooting or restarting the service would
> probably have done it too, what I mean is that inserts didn't start
> working again by just changing the setting).
> Is that something known?
AFAIK the Storage engine should throw an exception when the 2gb limit is
reached, but should not set the db in suspect mode... this is what I've been
always told, as I never pushed MSDE to that upper limit :D ...
and this is the very first time I hear about growth setting affect such a
behaviour.. will try investigating this...
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
error logs before leaving, an error logging table in an MSDE database has
made it grow to 2GB in a couple of days.
The result is that the database status became "suspect" (I had to connect
through enterprise manager to see that) and it can no longer be opened.
At the same time, I noticed that the $&*$##% has renamed the computer after
installing MSDE and initializing the database, despite my urging him never
to do so: as a result the backup schedule that's created along with the
database was no longer executed, the last backup dates from last April
instead of a few hours before it stopped working.
Needless to say that the customer is very happy.
Now I think I made an additional error by trying to detach and re-attach
the database: MSDE won't even re-attach it anymore, with an error "the
primary file group is full".
Is there a way to force MSDE to load it anyway so the extraneous data can
be deleted?
Can the file be attached to a full SQL server, the runaway table purged
there, and then re-attached to MSDE?
On Tue, 28 Dec 2004 12:14:46 +0100, Lucvdv <replace_name@.null.net> wrote:
> Because of a configuration error by field engineer who didn't check the
> error logs before leaving, an error logging table in an MSDE database has
> made it grow to 2GB in a couple of days.
I just tried to recreate the problem on a test machine: the .mdf file grew
to 1869 MB (1.82 GB), then it stopped with "PRIMARY file group full", but
the database remains accessible, only inserts fail.
In the problem case, the .mdf file was slightly over 2 GB (2.03GB or so, I
don't remember exactly.)
Is there an explanation for this?
|||On Tue, 28 Dec 2004 12:14:46 +0100, Lucvdv <replace_name@.null.net> wrote:
> Can the file be attached to a full SQL server, the runaway table purged
> there, and then re-attached to MSDE?
Relief all around: after copying and attaching the database to a full SQL
Server, shrinking it there and then moving it back to MSDE, everything is
up and running again.
|||hi,
"Lucvdv" <replace_name@.null.net> ha scritto nel messaggio
news:ivf2t0ln44sb9r9ll8ucnknidv4pg4ppad@.4ax.com
> ...
> Can the file be attached to a full SQL server, the runaway table
> purged there, and then re-attached to MSDE?
yes... you can get the mdf (+ ndf if present) + ldf database files set,
take them to your office, purge the "extra" data and shrink the database
data file(s) to a size allowed by MSDE..
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||On Tue, 28 Dec 2004 17:12:37 +0100, "Andrea Montanari"
<andrea.sqlDMO@.virgilio.it> wrote:
> hi,
> "Lucvdv" <replace_name@.null.net> ha scritto nel messaggio
> news:ivf2t0ln44sb9r9ll8ucnknidv4pg4ppad@.4ax.com
> yes... you can get the mdf (+ ndf if present) + ldf database files set,
> take them to your office, purge the "extra" data and shrink the database
> data file(s) to a size allowed by MSDE..
Thanks. I had tried and found that it worked shortly before you replied.
I tried to repeat it on a test machine later, but couldn't make the .mdf
grow above 2GB: all inserts started failing when the final file grow step
had to be done. It actually stopped around 1850 MB with % growth steps, it
refused to go closer to 2G until I changed that to 5MB fixed increments,
and then it stopped at 2044 MB.
The database remained usable, I could detach and attach it, only inserts
failed.
Yet in the problem case it was 2.03GB or something like that (slightly
above 2GB anyway), and MSDE refused to use it any further.
Do you have an idea how that might have happened?
I also noticed when I changed the file growth settings from % to fixed
size, that the change didn't take effect until I had detached and
re-attached the database (rebooting or restarting the service would
probably have done it too, what I mean is that inserts didn't start working
again by just changing the setting).
Is that something known?
|||hi Lucvdv,
"Lucvdv" <replace_name@.null.net> ha scritto nel messaggio
news:94r4t0p6bvclndb2l8gjuhogmd9ho8hq00@.4ax.com
> ...
> I tried to repeat it on a test machine later, but couldn't make the
> .mdf grow above 2GB: all inserts started failing when the final file
> grow step had to be done. It actually stopped around 1850 MB with %
> growth steps, it refused to go closer to 2G until I changed that to
> 5MB fixed increments, and then it stopped at 2044 MB.
> The database remained usable, I could detach and attach it, only
> inserts failed.
> Yet in the problem case it was 2.03GB or something like that (slightly
> above 2GB anyway), and MSDE refused to use it any further.
> Do you have an idea how that might have happened?
>
> I also noticed when I changed the file growth settings from % to fixed
> size, that the change didn't take effect until I had detached and
> re-attached the database (rebooting or restarting the service would
> probably have done it too, what I mean is that inserts didn't start
> working again by just changing the setting).
> Is that something known?
AFAIK the Storage engine should throw an exception when the 2gb limit is
reached, but should not set the db in suspect mode... this is what I've been
always told, as I never pushed MSDE to that upper limit :D ...
and this is the very first time I hear about growth setting affect such a
behaviour.. will try investigating this...
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
Subscribe to:
Posts (Atom)