Hello,
I've a problem with a application witch uses SQL Server 2000 STD. Other
applications on the same SQL instance have no problems.
Windows 2000 SBS SP4
SQL Server 2000 SP3a
- Running the application from console or TS session on the SQL server is
fast.
- Named pipes connection or tcp/ip connection no difference
- shut down other applications on the server has no results in performance
- New installed test server with SBS 2000 gives no problem
- The performance of the server like not the problem.Could you explain your question, please?
For example, what kind of conection do you use in the app.? , etc...
"GVWHIA" <GVWHIA@.discussions.microsoft.com> wrote in message
news:A6C849B2-C78B-4E66-B69E-0A888B7BDD70@.microsoft.com...
> Hello,
> I've a problem with a application witch uses SQL Server 2000 STD. Other
> applications on the same SQL instance have no problems.
> Windows 2000 SBS SP4
> SQL Server 2000 SP3a
> - Running the application from console or TS session on the SQL server is
> fast.
> - Named pipes connection or tcp/ip connection no difference
> - shut down other applications on the server has no results in performance
> - New installed test server with SBS 2000 gives no problem
> - The performance of the server like not the problem.|||On Tue, 7 Dec 2004 06:53:03 -0800, GVWHIA
<GVWHIA@.discussions.microsoft.com> wrote:
>I've a problem with a application witch uses SQL Server 2000 STD. Other
>applications on the same SQL instance have no problems.
Could it be examining huge amounts of data that clog the network when
run remotely?
J.
Showing posts with label applications. Show all posts
Showing posts with label applications. Show all posts
Monday, March 19, 2012
Friday, February 24, 2012
Backup/Restore Versus Detach/Attach
Hi All,
when I've to deploy my applications (c# and MSDE), generally I make a backup
on th edevelopment machine of the SQL Database the on the deployment machine
I make a restore and restoring from the backup I get my database up and
running (so boiring that I've to change the data/log file path at any
restore...).
Are there any real differences if instead of backup/restore I detach the
database file from the development machine (running sql developer edition)
then copy the file on the deployment machine and then make an attach to that
file?
which one is the best way?
Thanks, Davide.
Davide Piras
Naxo Software
hi Davide,
Davide Piras wrote:
> Hi All,
> when I've to deploy my applications (c# and MSDE), generally I make a
> backup on th edevelopment machine of the SQL Database the on the
> deployment machine I make a restore and restoring from the backup I
> get my database up and running (so boiring that I've to change the
> data/log file path at any restore...).
> Are there any real differences if instead of backup/restore I detach
> the database file from the development machine (running sql developer
> edition) then copy the file on the deployment machine and then make
> an attach to that file?
> which one is the best way?
please remember to add the log file to your distribution too, as it's part
of the dabase files set... and reattaching without the log file can end in
attaching problems...
the restore scenario only requires a little more physical space as you have
to consider the backup size in addition to the database files size...
both scenarios are simple to run but you have to consider some potential
issues..
MSDE usually set the "autoclose" database property, where the full blown SQL
Server editions do not, so you'll end up with a database that does not
reflect this standard MSDE setting, but it could be a choice...
you do not inherit database settings/options/objects from the end user model
database but from yours...
this can bring up some problems regarding orphaned users you will have to
fix by use of the sp_change_users_login system stored procedure
(http://msdn.microsoft.com/library/de...ca-cz_8qzy.asp
, http://www.sqlservercentral.com/colu...okenlogins.asp )
personally I go this way, http://tinyurl.com/dyjjg , that will even help in
structure upgrade to, and can grant a database deployment based on version
control check ... and the best article I found for this kind of situation is
http://msdn.microsoft.com/msdnmag/is...baseinstaller/
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.12.0 - DbaMgr ver 0.58.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||Ciao Andrea,
thanks for you help, I will read those articles BEFORE the next deployment
loop...
you know I use your DbaManager 0.12.0 as a Client User Interface?! :-)
Nice and useful Tool, thanks!
Davide.
when I've to deploy my applications (c# and MSDE), generally I make a backup
on th edevelopment machine of the SQL Database the on the deployment machine
I make a restore and restoring from the backup I get my database up and
running (so boiring that I've to change the data/log file path at any
restore...).
Are there any real differences if instead of backup/restore I detach the
database file from the development machine (running sql developer edition)
then copy the file on the deployment machine and then make an attach to that
file?
which one is the best way?
Thanks, Davide.
Davide Piras
Naxo Software
hi Davide,
Davide Piras wrote:
> Hi All,
> when I've to deploy my applications (c# and MSDE), generally I make a
> backup on th edevelopment machine of the SQL Database the on the
> deployment machine I make a restore and restoring from the backup I
> get my database up and running (so boiring that I've to change the
> data/log file path at any restore...).
> Are there any real differences if instead of backup/restore I detach
> the database file from the development machine (running sql developer
> edition) then copy the file on the deployment machine and then make
> an attach to that file?
> which one is the best way?
please remember to add the log file to your distribution too, as it's part
of the dabase files set... and reattaching without the log file can end in
attaching problems...
the restore scenario only requires a little more physical space as you have
to consider the backup size in addition to the database files size...
both scenarios are simple to run but you have to consider some potential
issues..
MSDE usually set the "autoclose" database property, where the full blown SQL
Server editions do not, so you'll end up with a database that does not
reflect this standard MSDE setting, but it could be a choice...
you do not inherit database settings/options/objects from the end user model
database but from yours...
this can bring up some problems regarding orphaned users you will have to
fix by use of the sp_change_users_login system stored procedure
(http://msdn.microsoft.com/library/de...ca-cz_8qzy.asp
, http://www.sqlservercentral.com/colu...okenlogins.asp )
personally I go this way, http://tinyurl.com/dyjjg , that will even help in
structure upgrade to, and can grant a database deployment based on version
control check ... and the best article I found for this kind of situation is
http://msdn.microsoft.com/msdnmag/is...baseinstaller/
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.12.0 - DbaMgr ver 0.58.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||Ciao Andrea,
thanks for you help, I will read those articles BEFORE the next deployment
loop...
you know I use your DbaManager 0.12.0 as a Client User Interface?! :-)
Nice and useful Tool, thanks!
Davide.
Subscribe to:
Posts (Atom)