This is a really strange error that I am seeing and I'm wondering if
anyone else has seen it yet.
I have a small database (less than 100k for backup file) that I send to a
third party. On several tables in this database there are fields that are
set to decimal(19,4). I am running SQL Server 2000 sp3/3a. Third party is
running 2K sp4. When they restore the database on their side, SOME of
these same numeric fields are showing a scale of 0, so in effect the scale
is lost and rather than reporting "1.5000" we are reporting a value of
"1". The precision and scale on third party's end is decimal(18,0).
Is there any way to explain why the scale for SOME of these fields is
changing? It's not even a complete conversion. There are some fields that
are not getting converted, which REALLY confuses me.
The only thing I can figure is that a version of the database with this
scale exists somewhere on the server and that when they do a restore,
somehow the scale for these fields is retained from that old database,
even though we are restoring from a backup. How this would happen, I have
no idea, but it is the only thing I can think of at this point.
Perhaps the database backup file contains multiple backups and the first
(older schema) is restored by default. You can check this with RESTORE
HEADERONLY:
RESTORE HEADERONLY
FROM DISK='C:\Backups\MyBackup.bak'
Hope this helps.
Dan Guzman
SQL Server MVP
"KBarrett" <kelseybarrett@.matteicos.com> wrote in message
news:op.szk8rrbkbpkth2@.tmc-kbarrett.matteicos.com...
> This is a really strange error that I am seeing and I'm wondering if
> anyone else has seen it yet.
> I have a small database (less than 100k for backup file) that I send to a
> third party. On several tables in this database there are fields that are
> set to decimal(19,4). I am running SQL Server 2000 sp3/3a. Third party is
> running 2K sp4. When they restore the database on their side, SOME of
> these same numeric fields are showing a scale of 0, so in effect the scale
> is lost and rather than reporting "1.5000" we are reporting a value of
> "1". The precision and scale on third party's end is decimal(18,0).
> Is there any way to explain why the scale for SOME of these fields is
> changing? It's not even a complete conversion. There are some fields that
> are not getting converted, which REALLY confuses me.
> The only thing I can figure is that a version of the database with this
> scale exists somewhere on the server and that when they do a restore,
> somehow the scale for these fields is retained from that old database,
> even though we are restoring from a backup. How this would happen, I have
> no idea, but it is the only thing I can think of at this point.
>
|||Thanks for the tip Dan. I will check on that.
-k
On Tue, 01 Nov 2005 20:35:28 -0800, Dan Guzman
<guzmanda@.nospam-online.sbcglobal.net> wrote:
> Perhaps the database backup file contains multiple backups and the first
> (older schema) is restored by default. You can check this with RESTORE
> HEADERONLY:
> RESTORE HEADERONLY
> FROM DISK='C:\Backups\MyBackup.bak'
Showing posts with label strange. Show all posts
Showing posts with label strange. Show all posts
Wednesday, March 28, 2012
Precision Scale Problems Between SQL 2K SP3 and SP4
This is a really strange error that I am seeing and I'm wondering if
anyone else has seen it yet.
I have a small database (less than 100k for backup file) that I send to a
third party. On several tables in this database there are fields that are
set to decimal(19,4). I am running SQL Server 2000 sp3/3a. Third party is
running 2K sp4. When they restore the database on their side, SOME of
these same numeric fields are showing a scale of 0, so in effect the scale
is lost and rather than reporting "1.5000" we are reporting a value of
"1". The precision and scale on third party's end is decimal(18,0).
Is there any way to explain why the scale for SOME of these fields is
changing? It's not even a complete conversion. There are some fields that
are not getting converted, which REALLY confuses me.
The only thing I can figure is that a version of the database with this
scale exists somewhere on the server and that when they do a restore,
somehow the scale for these fields is retained from that old database,
even though we are restoring from a backup. How this would happen, I have
no idea, but it is the only thing I can think of at this point.Perhaps the database backup file contains multiple backups and the first
(older schema) is restored by default. You can check this with RESTORE
HEADERONLY:
RESTORE HEADERONLY
FROM DISK='C:\Backups\MyBackup.bak'
--
Hope this helps.
Dan Guzman
SQL Server MVP
"KBarrett" <kelseybarrett@.matteicos.com> wrote in message
news:op.szk8rrbkbpkth2@.tmc-kbarrett.matteicos.com...
> This is a really strange error that I am seeing and I'm wondering if
> anyone else has seen it yet.
> I have a small database (less than 100k for backup file) that I send to a
> third party. On several tables in this database there are fields that are
> set to decimal(19,4). I am running SQL Server 2000 sp3/3a. Third party is
> running 2K sp4. When they restore the database on their side, SOME of
> these same numeric fields are showing a scale of 0, so in effect the scale
> is lost and rather than reporting "1.5000" we are reporting a value of
> "1". The precision and scale on third party's end is decimal(18,0).
> Is there any way to explain why the scale for SOME of these fields is
> changing? It's not even a complete conversion. There are some fields that
> are not getting converted, which REALLY confuses me.
> The only thing I can figure is that a version of the database with this
> scale exists somewhere on the server and that when they do a restore,
> somehow the scale for these fields is retained from that old database,
> even though we are restoring from a backup. How this would happen, I have
> no idea, but it is the only thing I can think of at this point.
>|||Thanks for the tip Dan. I will check on that.
-k
On Tue, 01 Nov 2005 20:35:28 -0800, Dan Guzman
<guzmanda@.nospam-online.sbcglobal.net> wrote:
> Perhaps the database backup file contains multiple backups and the first
> (older schema) is restored by default. You can check this with RESTORE
> HEADERONLY:
> RESTORE HEADERONLY
> FROM DISK='C:\Backups\MyBackup.bak'
anyone else has seen it yet.
I have a small database (less than 100k for backup file) that I send to a
third party. On several tables in this database there are fields that are
set to decimal(19,4). I am running SQL Server 2000 sp3/3a. Third party is
running 2K sp4. When they restore the database on their side, SOME of
these same numeric fields are showing a scale of 0, so in effect the scale
is lost and rather than reporting "1.5000" we are reporting a value of
"1". The precision and scale on third party's end is decimal(18,0).
Is there any way to explain why the scale for SOME of these fields is
changing? It's not even a complete conversion. There are some fields that
are not getting converted, which REALLY confuses me.
The only thing I can figure is that a version of the database with this
scale exists somewhere on the server and that when they do a restore,
somehow the scale for these fields is retained from that old database,
even though we are restoring from a backup. How this would happen, I have
no idea, but it is the only thing I can think of at this point.Perhaps the database backup file contains multiple backups and the first
(older schema) is restored by default. You can check this with RESTORE
HEADERONLY:
RESTORE HEADERONLY
FROM DISK='C:\Backups\MyBackup.bak'
--
Hope this helps.
Dan Guzman
SQL Server MVP
"KBarrett" <kelseybarrett@.matteicos.com> wrote in message
news:op.szk8rrbkbpkth2@.tmc-kbarrett.matteicos.com...
> This is a really strange error that I am seeing and I'm wondering if
> anyone else has seen it yet.
> I have a small database (less than 100k for backup file) that I send to a
> third party. On several tables in this database there are fields that are
> set to decimal(19,4). I am running SQL Server 2000 sp3/3a. Third party is
> running 2K sp4. When they restore the database on their side, SOME of
> these same numeric fields are showing a scale of 0, so in effect the scale
> is lost and rather than reporting "1.5000" we are reporting a value of
> "1". The precision and scale on third party's end is decimal(18,0).
> Is there any way to explain why the scale for SOME of these fields is
> changing? It's not even a complete conversion. There are some fields that
> are not getting converted, which REALLY confuses me.
> The only thing I can figure is that a version of the database with this
> scale exists somewhere on the server and that when they do a restore,
> somehow the scale for these fields is retained from that old database,
> even though we are restoring from a backup. How this would happen, I have
> no idea, but it is the only thing I can think of at this point.
>|||Thanks for the tip Dan. I will check on that.
-k
On Tue, 01 Nov 2005 20:35:28 -0800, Dan Guzman
<guzmanda@.nospam-online.sbcglobal.net> wrote:
> Perhaps the database backup file contains multiple backups and the first
> (older schema) is restored by default. You can check this with RESTORE
> HEADERONLY:
> RESTORE HEADERONLY
> FROM DISK='C:\Backups\MyBackup.bak'
Precision Scale Problems Between SQL 2K SP3 and SP4
This is a really strange error that I am seeing and I'm wondering if
anyone else has seen it yet.
I have a small database (less than 100k for backup file) that I send to a
third party. On several tables in this database there are fields that are
set to decimal(19,4). I am running SQL Server 2000 sp3/3a. Third party is
running 2K sp4. When they restore the database on their side, SOME of
these same numeric fields are showing a scale of 0, so in effect the scale
is lost and rather than reporting "1.5000" we are reporting a value of
"1". The precision and scale on third party's end is decimal(18,0).
Is there any way to explain why the scale for SOME of these fields is
changing? It's not even a complete conversion. There are some fields that
are not getting converted, which REALLY confuses me.
The only thing I can figure is that a version of the database with this
scale exists somewhere on the server and that when they do a restore,
somehow the scale for these fields is retained from that old database,
even though we are restoring from a backup. How this would happen, I have
no idea, but it is the only thing I can think of at this point.Perhaps the database backup file contains multiple backups and the first
(older schema) is restored by default. You can check this with RESTORE
HEADERONLY:
RESTORE HEADERONLY
FROM DISK='C:\Backups\MyBackup.bak'
Hope this helps.
Dan Guzman
SQL Server MVP
"KBarrett" <kelseybarrett@.matteicos.com> wrote in message
news:op.szk8rrbkbpkth2@.tmc-kbarrett.matteicos.com...
> This is a really strange error that I am seeing and I'm wondering if
> anyone else has seen it yet.
> I have a small database (less than 100k for backup file) that I send to a
> third party. On several tables in this database there are fields that are
> set to decimal(19,4). I am running SQL Server 2000 sp3/3a. Third party is
> running 2K sp4. When they restore the database on their side, SOME of
> these same numeric fields are showing a scale of 0, so in effect the scale
> is lost and rather than reporting "1.5000" we are reporting a value of
> "1". The precision and scale on third party's end is decimal(18,0).
> Is there any way to explain why the scale for SOME of these fields is
> changing? It's not even a complete conversion. There are some fields that
> are not getting converted, which REALLY confuses me.
> The only thing I can figure is that a version of the database with this
> scale exists somewhere on the server and that when they do a restore,
> somehow the scale for these fields is retained from that old database,
> even though we are restoring from a backup. How this would happen, I have
> no idea, but it is the only thing I can think of at this point.
>|||Thanks for the tip Dan. I will check on that.
-k
On Tue, 01 Nov 2005 20:35:28 -0800, Dan Guzman
<guzmanda@.nospam-online.sbcglobal.net> wrote:
> Perhaps the database backup file contains multiple backups and the first
> (older schema) is restored by default. You can check this with RESTORE
> HEADERONLY:
> RESTORE HEADERONLY
> FROM DISK='C:\Backups\MyBackup.bak'
anyone else has seen it yet.
I have a small database (less than 100k for backup file) that I send to a
third party. On several tables in this database there are fields that are
set to decimal(19,4). I am running SQL Server 2000 sp3/3a. Third party is
running 2K sp4. When they restore the database on their side, SOME of
these same numeric fields are showing a scale of 0, so in effect the scale
is lost and rather than reporting "1.5000" we are reporting a value of
"1". The precision and scale on third party's end is decimal(18,0).
Is there any way to explain why the scale for SOME of these fields is
changing? It's not even a complete conversion. There are some fields that
are not getting converted, which REALLY confuses me.
The only thing I can figure is that a version of the database with this
scale exists somewhere on the server and that when they do a restore,
somehow the scale for these fields is retained from that old database,
even though we are restoring from a backup. How this would happen, I have
no idea, but it is the only thing I can think of at this point.Perhaps the database backup file contains multiple backups and the first
(older schema) is restored by default. You can check this with RESTORE
HEADERONLY:
RESTORE HEADERONLY
FROM DISK='C:\Backups\MyBackup.bak'
Hope this helps.
Dan Guzman
SQL Server MVP
"KBarrett" <kelseybarrett@.matteicos.com> wrote in message
news:op.szk8rrbkbpkth2@.tmc-kbarrett.matteicos.com...
> This is a really strange error that I am seeing and I'm wondering if
> anyone else has seen it yet.
> I have a small database (less than 100k for backup file) that I send to a
> third party. On several tables in this database there are fields that are
> set to decimal(19,4). I am running SQL Server 2000 sp3/3a. Third party is
> running 2K sp4. When they restore the database on their side, SOME of
> these same numeric fields are showing a scale of 0, so in effect the scale
> is lost and rather than reporting "1.5000" we are reporting a value of
> "1". The precision and scale on third party's end is decimal(18,0).
> Is there any way to explain why the scale for SOME of these fields is
> changing? It's not even a complete conversion. There are some fields that
> are not getting converted, which REALLY confuses me.
> The only thing I can figure is that a version of the database with this
> scale exists somewhere on the server and that when they do a restore,
> somehow the scale for these fields is retained from that old database,
> even though we are restoring from a backup. How this would happen, I have
> no idea, but it is the only thing I can think of at this point.
>|||Thanks for the tip Dan. I will check on that.
-k
On Tue, 01 Nov 2005 20:35:28 -0800, Dan Guzman
<guzmanda@.nospam-online.sbcglobal.net> wrote:
> Perhaps the database backup file contains multiple backups and the first
> (older schema) is restored by default. You can check this with RESTORE
> HEADERONLY:
> RESTORE HEADERONLY
> FROM DISK='C:\Backups\MyBackup.bak'
Friday, March 23, 2012
Post-Relational Databases
I just recently came across Post-Relational databases, strange I never heard
of them before. Anyone any experience of them, are they going to be the next
generation of databases as I heard one guy claim!?
Thanks
NYes, that old dilemma - is reality made up of relations or objects? :)
ML
http://milambda.blogspot.com/|||So its just an OO Database. I'm a relational man myself!
"NH" wrote:
> I just recently came across Post-Relational databases, strange I never hea
rd
> of them before. Anyone any experience of them, are they going to be the ne
xt
> generation of databases as I heard one guy claim!?
> Thanks
> N|||I thought we realted objects in the relational database :)
"ML" wrote:
> Yes, that old dilemma - is reality made up of relations or objects? :)
>
> ML
> --
> http://milambda.blogspot.com/|||ML wrote:
> Yes, that old dilemma - is reality made up of relations or objects? :)
>
Neither. Both are abstractions. What does "post-relational" mean to
you?
More appropriate for comp.databases.theory anyway.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||> Neither. Both are abstractions.
Absolutely. No argument there.
> What does "post-relational" mean to you?
Seriously? Well, no offense indended but the first time I heard this
expression I thought it had to do with divorce. Maybe even a weird
puritanistic definition of the state two (or more) sexual partners are in
after sexual intercourse.
ML
http://milambda.blogspot.com/|||"ML" <ML@.discussions.microsoft.com> wrote in message
news:9E68AE41-2414-4B49-A8BE-FC078B2D4BA8@.microsoft.com...
> Absolutely. No argument there.
>
> Seriously? Well, no offense indended but the first time I heard this
> expression I thought it had to do with divorce. Maybe even a weird
> puritanistic definition of the state two (or more) sexual partners are in
> after sexual intercourse.
>
> ML
> --
> http://milambda.blogspot.com/
I get it. NH's posts didn't show up at first so I thought you started the
thread.
Post-relational is what XML fans call the hierachical model. The rest of us
call it Pre-Relational.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx|||A brief look at Matisse (for example) gives the impression of another layer
of abstraction on top of a "regular" relational model.
Sometimes abstraction is good, but sooner or later...
abstraction = confusion
ML
http://milambda.blogspot.com/|||> Post-relational is what XML fans call the hierachical model. The rest of us call it[color
=darkred]
> Pre-Relational.[/color]
LOL!
That's a classic.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:es6j0GzfGHA.5092@.TK2MSFTNGP04.phx.gbl...
> "ML" <ML@.discussions.microsoft.com> wrote in message
> news:9E68AE41-2414-4B49-A8BE-FC078B2D4BA8@.microsoft.com...
> I get it. NH's posts didn't show up at first so I thought you started the
thread.
> Post-relational is what XML fans call the hierachical model. The rest of u
s call it
> Pre-Relational.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>
>|||"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1148473208.702352.33010@.g10g2000cwb.googlegroups.com...
> More appropriate for comp.databases.theory anyway.
Yup. We never get into theory in this forum.
=P
of them before. Anyone any experience of them, are they going to be the next
generation of databases as I heard one guy claim!?
Thanks
NYes, that old dilemma - is reality made up of relations or objects? :)
ML
http://milambda.blogspot.com/|||So its just an OO Database. I'm a relational man myself!
"NH" wrote:
> I just recently came across Post-Relational databases, strange I never hea
rd
> of them before. Anyone any experience of them, are they going to be the ne
xt
> generation of databases as I heard one guy claim!?
> Thanks
> N|||I thought we realted objects in the relational database :)
"ML" wrote:
> Yes, that old dilemma - is reality made up of relations or objects? :)
>
> ML
> --
> http://milambda.blogspot.com/|||ML wrote:
> Yes, that old dilemma - is reality made up of relations or objects? :)
>
Neither. Both are abstractions. What does "post-relational" mean to
you?
More appropriate for comp.databases.theory anyway.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||> Neither. Both are abstractions.
Absolutely. No argument there.
> What does "post-relational" mean to you?
Seriously? Well, no offense indended but the first time I heard this
expression I thought it had to do with divorce. Maybe even a weird
puritanistic definition of the state two (or more) sexual partners are in
after sexual intercourse.
ML
http://milambda.blogspot.com/|||"ML" <ML@.discussions.microsoft.com> wrote in message
news:9E68AE41-2414-4B49-A8BE-FC078B2D4BA8@.microsoft.com...
> Absolutely. No argument there.
>
> Seriously? Well, no offense indended but the first time I heard this
> expression I thought it had to do with divorce. Maybe even a weird
> puritanistic definition of the state two (or more) sexual partners are in
> after sexual intercourse.
>
> ML
> --
> http://milambda.blogspot.com/
I get it. NH's posts didn't show up at first so I thought you started the
thread.
Post-relational is what XML fans call the hierachical model. The rest of us
call it Pre-Relational.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx|||A brief look at Matisse (for example) gives the impression of another layer
of abstraction on top of a "regular" relational model.
Sometimes abstraction is good, but sooner or later...
abstraction = confusion
ML
http://milambda.blogspot.com/|||> Post-relational is what XML fans call the hierachical model. The rest of us call it[color
=darkred]
> Pre-Relational.[/color]
LOL!
That's a classic.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:es6j0GzfGHA.5092@.TK2MSFTNGP04.phx.gbl...
> "ML" <ML@.discussions.microsoft.com> wrote in message
> news:9E68AE41-2414-4B49-A8BE-FC078B2D4BA8@.microsoft.com...
> I get it. NH's posts didn't show up at first so I thought you started the
thread.
> Post-relational is what XML fans call the hierachical model. The rest of u
s call it
> Pre-Relational.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>
>|||"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1148473208.702352.33010@.g10g2000cwb.googlegroups.com...
> More appropriate for comp.databases.theory anyway.
Yup. We never get into theory in this forum.
=P
Subscribe to:
Posts (Atom)