By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,261 Members | 2,662 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,261 IT Pros & Developers. It's quick & easy.

Differences between SQL Server Versions

P: n/a
Hello,

I've got installed Win 2003 SBS Premium with the SQL Server 2000 on a server
machine. It works almost fine, except the application which uses the SQL
Server. The main part of the application runs (since the last update) fine,
but other tools of that application (database import and the database
manager for check and rebuild) doesn't. They hang up or kill the database.

Our software developer says that these problems are in correlation with the
server os. But there won't be any problem if we install Win 2000 Server and
add an additional SQL Server 2000.

Finally my question is: Are there any differences between the SQL Server
2000 Versions, which are sold (a) as a single product, (b) as part of the
Win 2003 SBS Premium package and (c) as part of other Server versions?

Thanks in Advance,

Martin
Jul 20 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Hi

I believe the component products that are packaged in SBS and their singular
produces are effectively the same. Comparing windows 2000 and windows 2003
is not a like for like comparison, and you don't say is if it is the same
hardware. It is also not clear where these applications are located and how
they access the database. Security in Windows 2003 is significantly tighter
and therefore you may be assuming something that had a lax default in
Windows 2000 is still the case, the may explain some of the application
failures. For the other problems check out your SQL Server configuration is
the same as your previous one, also look at the SQL Server logs and the
Event logs for any messages being logged when the problems occur. Profiler
may also help as well as running the applications in debug mode.

John

"Martin Meyer im Hagen" <an@mmih.de> wrote in message
news:cd*************@news.t-online.com...
Hello,

I've got installed Win 2003 SBS Premium with the SQL Server 2000 on a server machine. It works almost fine, except the application which uses the SQL
Server. The main part of the application runs (since the last update) fine, but other tools of that application (database import and the database
manager for check and rebuild) doesn't. They hang up or kill the database.

Our software developer says that these problems are in correlation with the server os. But there won't be any problem if we install Win 2000 Server and add an additional SQL Server 2000.

Finally my question is: Are there any differences between the SQL Server
2000 Versions, which are sold (a) as a single product, (b) as part of the
Win 2003 SBS Premium package and (c) as part of other Server versions?

Thanks in Advance,

Martin

Jul 20 '05 #2

P: n/a
Martin Meyer im Hagen (an@mmih.de) writes:
I've got installed Win 2003 SBS Premium with the SQL Server 2000 on a
server machine. It works almost fine, except the application which uses
the SQL Server. The main part of the application runs (since the last
update) fine, but other tools of that application (database import and
the database manager for check and rebuild) doesn't. They hang up or
kill the database.

Our software developer says that these problems are in correlation with
the server os. But there won't be any problem if we install Win 2000
Server and add an additional SQL Server 2000.

Finally my question is: Are there any differences between the SQL Server
2000 Versions, which are sold (a) as a single product, (b) as part of the
Win 2003 SBS Premium package and (c) as part of other Server versions?


There are a couple of different editions of SQL Server: Enterprise,
Standard, Personal, Developer and MSDE (Desktop Engine). There are indeed
differences between these editions. I doubt however that these differences
can account for the problems you are seeing. Even less would I believe
in that the operating system matters.

I am more inclined to blame that on poor applicataion design. Then again,
you description does not offer much detail, so I could be wrong.

I don't know what editiion might have, but my guess would be Standard.
You can find out, with this SELECT statement:

select serverproperty('Edition')

You can run this from Query Analyzer or the command-line tool OSQL.

--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 20 '05 #3

P: n/a
"Erland Sommarskog" <es****@sommarskog.se> schrieb im Newsbeitrag
news:Xn**********************@127.0.0.1...
Martin Meyer im Hagen (an@mmih.de) writes:
There are a couple of different editions of SQL Server: Enterprise,
Standard, Personal, Developer and MSDE (Desktop Engine). There are indeed
differences between these editions. I doubt however that these differences
can account for the problems you are seeing. Even less would I believe
in that the operating system matters.


I think that it's the Standard edition that we use, but I can't check it
now. Definively it's not the MSDE version

Something about our Server's Hardware: AMD Athlon 2600+, Chaintech 7NJS UZ
(nForce2), 1024 MB RAM, 2*160 GB RAID1 (mirror) on Adaptec 1200A, Win 2003
SBS (without Exchange, Active Directory, Frontpage, Firewall etc.). Our
trader recommends to install a Win 2000 Server or Win 2000 SBS (with the
included SQL Server) or with a separate version of the SQL Server. The
server isn't connected to the internet and in this moment not running an
antivirus solution (CA eTrust is already avaible but not installed yet).

Before we had switched to the server we had used the MSDE on a local machine
(for only one user). Now we want to use the application on 2 workstations
via LAN with an extra database server (higher performance and the
possibility to import more article datas).

My problem is that the trader of our most important 'office' program says
that our version of the MS SQL Server isn't officially supported. In the
newest version it's possible to use the main functions of the database, but
an important import function doesn't work. Further the reindex (a third
programm of that package) destroys the database!

A friend told me that there might be a newer database version used in our
SQL Server and that the application makes some bad requests which doesn't
make any effect (instand of the log file, which growed up from 30 MB to 2
GB) or kill the database.

have a nice day,
Martin

---
127.0.0.1 is the best place on earth.
Jul 20 '05 #4

P: n/a
Martin Meyer im Hagen (an@mmih.de) writes:
Something about our Server's Hardware: AMD Athlon 2600+, Chaintech 7NJS UZ
(nForce2), 1024 MB RAM, 2*160 GB RAID1 (mirror) on Adaptec 1200A, Win 2003
SBS (without Exchange, Active Directory, Frontpage, Firewall etc.). Our
trader recommends to install a Win 2000 Server or Win 2000 SBS (with the
included SQL Server) or with a separate version of the SQL Server. The
server isn't connected to the internet and in this moment not running an
antivirus solution (CA eTrust is already avaible but not installed yet).
Excuse a language question, but when you say "trader", do you mean a
representative of the company from which you have bought the application
you are having problem with?
My problem is that the trader of our most important 'office' program says
that our version of the MS SQL Server isn't officially supported.
So which version of MS SQL Server does he claim to support?

The current service pack of SQL Server 2000 is SP3, and it has been out
for one year and a half, and if he does not support that it's a cry and
shame.

It could be that he is not supporting Windows 2003, but that, too, would
be quite some egg on his face.
In the newest version it's possible to use the main functions of the
database, but an important import function doesn't work. Further the
reindex (a third programm of that package) destroys the database!
Sounds serious, but without further information it's a little difficult
to comment. Normally, when you talk about reindexing and SQL Server,
this is a command within SQL Server, and it should not destroy your
database.
A friend told me that there might be a newer database version used in our
SQL Server and that the application makes some bad requests which doesn't
make any effect (instand of the log file, which growed up from 30 MB to 2
GB) or kill the database.


It could be an issue of recovery modes. The default is ro run with
full recovery, and if you want up-to-the-minute recovery in case of
a crash, or a fatal incorrect update, you need full recovery. In that
case, you also need to back up the transaction log regularly. But if
you are content with restoring the latest backup, you can run with
simple recovery. Then you don't have to bother about the transaction log.

--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 20 '05 #5

P: n/a
"Erland Sommarskog" <es****@sommarskog.se> schrieb im Newsbeitrag
news:Xn*********************@127.0.0.1...
Excuse a language question, but when you say "trader", do you mean a
representative of the company from which you have bought the application
you are having problem with?
Yes, that is the person.
My problem is that the trader of our most important 'office' program says that our version of the MS SQL Server isn't officially supported.


So which version of MS SQL Server does he claim to support?

The current service pack of SQL Server 2000 is SP3, and it has been out
for one year and a half, and if he does not support that it's a cry and
shame.


SP3 is installed.
It could be that he is not supporting Windows 2003, but that, too, would
be quite some egg on his face.
In the newest version it's possible to use the main functions of the
database, but an important import function doesn't work. Further the
reindex (a third programm of that package) destroys the database!
Sounds serious, but without further information it's a little difficult
to comment. Normally, when you talk about reindexing and SQL Server,
this is a command within SQL Server, and it should not destroy your
database.


I've read in the manual: that function reindexes the database, checks it for
errors and other bad stuff. If you choose Auto-Repair it destroys the
database, if you doesn't do anything.
It could be an issue of recovery modes. The default is ro run with
full recovery, and if you want up-to-the-minute recovery in case of
a crash, or a fatal incorrect update, you need full recovery. In that
case, you also need to back up the transaction log regularly. But if
you are content with restoring the latest backup, you can run with
simple recovery. Then you don't have to bother about the transaction log.


Since we've got the server installed I'm very familiar with backup and
recovery. There shouldn't been any problems because of the limitation of the
MSDE we had used before? I've 'copied' the database via backup and recovery.

have a nice day,
Martin

---
127.0.0.1 is the best place on earth.
Jul 20 '05 #6

P: n/a
Martin Meyer im Hagen (an@mmih.de) writes:
"Erland Sommarskog" <es****@sommarskog.se> schrieb im Newsbeitrag
news:Xn*********************@127.0.0.1...
Sounds serious, but without further information it's a little difficult
to comment. Normally, when you talk about reindexing and SQL Server,
this is a command within SQL Server, and it should not destroy your
database.
I've read in the manual: that function reindexes the database, checks it
for errors and other bad stuff. If you choose Auto-Repair it destroys
the database, if you doesn't do anything.


Does it actually say in the manual that it destroys the database?

Anyway, it sounds very much to me that the application runs DBCC DBREINDEX
and DBCC CHECKDB. CHECKDB does indeed have a couple of auto-repair options.
Howeve it should not destroy the database. However, one the of the repair
options is REPAIR_ALLOW_DATA_LOSS, which means that if the internal
structure in the database is damaged, DBCC tries to repair those errors,
even if this leads to data being lost.

Your description is very vague. You have talked about "kill", "hang up"
or "destroy" the database. That tells me very little. I would need to
have more exact description of what happens. Does SQL Server become
unresponsive when you run the reindexing and auto-repair? Or does the
database remain inaccessible even after these jobs have completed? Do
you get any error messages along the way?

It goes without saying that if the application is using DBCC that SP3
should not be a problem.
Since we've got the server installed I'm very familiar with backup and
recovery. There shouldn't been any problems because of the limitation of
the MSDE we had used before? I've 'copied' the database via backup and
recovery.


Let's see in MSDE, the default recovery model is simple I believe.
And since you used MSDE before, the database can not be that big? The
reason I am interested in the size, is of course the bigger the database
the longer will CHECKDB and REINDEX take.

You can check the current recovery model with sp_helpdb.
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 20 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.