We are migrating our SQL 6.5 application to SQL 2000 & having some difficulties for one Stored procedure . It is failing . Is there any problem
with "TINYINT" ? . Same stored procedure is working fine in SQL 6.5.
We are getting error msg while inserting some rows in following table.
tbl_sd_cmp_hier_detail
(
cmp_hier_id tinyint,
prnt_cmp_int smallint,
chld_cmp_int smallint
)
i will appriciate any help on this.Originally posted by ajayu
We are migrating our SQL 6.5 application to SQL 2000 & having some difficulties for one Stored procedure . It is failing . Is there any problem
with "TINYINT" ? . Same stored procedure is working fine in SQL 6.5.
We are getting error msg while inserting some rows in following table.
tbl_sd_cmp_hier_detail
(
cmp_hier_id tinyint,
prnt_cmp_int smallint,
chld_cmp_int smallint
)
i will appriciate any help on this.
There shouldn't be any problem with SQL 2000. I just ran this code in 2000:
USE pubs
GO
CREATE TABLE tbl_sd_cmp_hier_detail (
cmp_hier_id tinyint,
prnt_cmp_int smallint,
chld_cmp_int smallint
)
GO
INSERT INTO tbl_sd_cmp_hier_detail (
cmp_hier_id,
prnt_cmp_int,
chld_cmp_int
)
VALUES (
123,
456,
789
)
GO
SELECT * FROM dbo.tbl_sd_cmp_hier_detail
GO
I got this:
cmp_hier_id prnt_cmp_int chld_cmp_int
---- ---- ----
123 456 789
Try the code I pasted here. If that works, there is probably some other problem with the stored procedure.
Rob
Showing posts with label difficulties. Show all posts
Showing posts with label difficulties. Show all posts
Wednesday, March 7, 2012
Migration from PervasiveSQL 7 to SQL Server 2000(Recomendations)
*sorry for spelling mistakes - im forigne
If you have experience with this procedure please let me know of any difficulties/problems that occured because of the change over. What procedure did you go through to make them compatible and perform at a reasonable level? Do you know the appox. size increase of the database (GB/MB) from one version to the other?
Current platform:
Compaq Proliant
Netware 4.5
4.5 GB database (accounting/inventory)
New platform:
IBM eserver X235
Win 2000 SQL Server
avalible HDD space approx. 100gb
If you could make any suggestions it would be appreciated.bump
If you have experience with this procedure please let me know of any difficulties/problems that occured because of the change over. What procedure did you go through to make them compatible and perform at a reasonable level? Do you know the appox. size increase of the database (GB/MB) from one version to the other?
Current platform:
Compaq Proliant
Netware 4.5
4.5 GB database (accounting/inventory)
New platform:
IBM eserver X235
Win 2000 SQL Server
avalible HDD space approx. 100gb
If you could make any suggestions it would be appreciated.bump
Monday, February 20, 2012
Migrating to SQL Server 2005 and Clustering
I have a fairly unique scenario, and I would like to see if anyone can point
out any potential holes of difficulties with this migration plan:
What client has -- 1 SQL Server 2000 enterprise Edition running on SQL 2003
NOT clustered, and using a SCSI disk array.
What client wants -- 2 SQL Server 2005 systems, running on a 2 node cluster
(Active-Passive) using a shared FiberChannel SAN. The active system will be
new, the failover system will be current system listed above. Note that
Clustering HCL has already been verified.
Goals -- provide ability to perform a gradual, testable migration from SQL
Server 2000 to SQL Server 2005 Cluster
Plan:
1) Setup New Server and SAN. Connect Both New server and old server to SAN
2) Install MS Clustering service on both servers, keeping original
un-clustered SQL 2000 in production
3) Install new instance of SQL 2005 on cluster
4) Test and then migrate databases from SQL Server 2000 to new SQL Server
2005 cluster one at a time. This means running the non-clustered SQL 2000 on
the physical hardware as the clustered SQL 2005 failover node. I realize
that failover probably wont work well during the transition, due to a lack of
resources.
5) When transition is complete, remove SQL Server 2000 from failover node.
Any thoughts or comments would be greatly appreciated.
Thanks,
Paul
My only concern is that you are reusing the existing node as a cluster node.
For simplicity's sake, I would create a a clustered installation without
reusing any of the existing hardware. You then have the original system
completely untouched during the transition. You don't need to connect the
existing SQL server to the SAN to do a minimal down time transfer. Given
proper set up time, I can do a server cutover in less than 15 minutes,
regardless of the total database size or count. Since you are moving one DB
at a time, it even gets easier.
If you have to reuse the existing hardware, I would add it to the cluster
after migration is complete. Install the cluster to a single-node, perform
the migration/cutover, and then reload the OS and add the node to the
cluster. You won't have failover redundancy until the project is complete,
but since you don't have that now, you won't miss it.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"PMartin" <PMartin@.discussions.microsoft.com> wrote in message
news:413AB596-D87F-4EFD-93E3-5335FAC3D647@.microsoft.com...
>I have a fairly unique scenario, and I would like to see if anyone can
>point
> out any potential holes of difficulties with this migration plan:
> What client has -- 1 SQL Server 2000 enterprise Edition running on SQL
> 2003
> NOT clustered, and using a SCSI disk array.
> What client wants -- 2 SQL Server 2005 systems, running on a 2 node
> cluster
> (Active-Passive) using a shared FiberChannel SAN. The active system will
> be
> new, the failover system will be current system listed above. Note that
> Clustering HCL has already been verified.
> Goals -- provide ability to perform a gradual, testable migration from SQL
> Server 2000 to SQL Server 2005 Cluster
> Plan:
> 1) Setup New Server and SAN. Connect Both New server and old server to
> SAN
> 2) Install MS Clustering service on both servers, keeping original
> un-clustered SQL 2000 in production
> 3) Install new instance of SQL 2005 on cluster
> 4) Test and then migrate databases from SQL Server 2000 to new SQL Server
> 2005 cluster one at a time. This means running the non-clustered SQL 2000
> on
> the physical hardware as the clustered SQL 2005 failover node. I realize
> that failover probably wont work well during the transition, due to a lack
> of
> resources.
> 5) When transition is complete, remove SQL Server 2000 from failover
> node.
> Any thoughts or comments would be greatly appreciated.
> Thanks,
> Paul
>
|||Geoff,
Unfortunately, we do need to re-use the hardware, so your suggestion of
installing a single node cluster sounds like oustanding advice. The lack of
failover during the transition will not be critical.
You mentioned reloading the OS on the current (soon to be failover) server.
Is this neceessary with Windows 2003, or just wise a precaution?
Thanks again!
Paul
"Geoff N. Hiten" wrote:
> My only concern is that you are reusing the existing node as a cluster node.
> For simplicity's sake, I would create a a clustered installation without
> reusing any of the existing hardware. You then have the original system
> completely untouched during the transition. You don't need to connect the
> existing SQL server to the SAN to do a minimal down time transfer. Given
> proper set up time, I can do a server cutover in less than 15 minutes,
> regardless of the total database size or count. Since you are moving one DB
> at a time, it even gets easier.
> If you have to reuse the existing hardware, I would add it to the cluster
> after migration is complete. Install the cluster to a single-node, perform
> the migration/cutover, and then reload the OS and add the node to the
> cluster. You won't have failover redundancy until the project is complete,
> but since you don't have that now, you won't miss it.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "PMartin" <PMartin@.discussions.microsoft.com> wrote in message
> news:413AB596-D87F-4EFD-93E3-5335FAC3D647@.microsoft.com...
>
>
|||I have prefer clean OS installs over upgrades. I have never personally had
any problems with 2000-2003 upgrades, but I have had issues with earlier OS
upgrade paths. I have even go so far as to upgrade each node in a cluster
then go back and wipe and reload each node, just so I don't have any
leftover bits. Since you will be migrating a W2000/SQL 2000 standalone host
to a W2003/SQL2005 clustered host, I would definitely wipe the system and
start over. If nothing else, you can guarantee it is an exact OS match for
its peer node.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"PMartin" <PMartin@.discussions.microsoft.com> wrote in message
news:F8076304-BBFE-4447-B0D8-D7A39F0544D4@.microsoft.com...[vbcol=seagreen]
> Geoff,
> Unfortunately, we do need to re-use the hardware, so your suggestion of
> installing a single node cluster sounds like oustanding advice. The lack
> of
> failover during the transition will not be critical.
> You mentioned reloading the OS on the current (soon to be failover)
> server.
> Is this neceessary with Windows 2003, or just wise a precaution?
> Thanks again!
> Paul
> "Geoff N. Hiten" wrote:
|||I don't see anything wrong with this. It's the way that I've upgraded more
than one system already.
Mike
Mentor
Solid Quality Learning
http://www.solidqualitylearning.com
"PMartin" <PMartin@.discussions.microsoft.com> wrote in message
news:413AB596-D87F-4EFD-93E3-5335FAC3D647@.microsoft.com...
>I have a fairly unique scenario, and I would like to see if anyone can
>point
> out any potential holes of difficulties with this migration plan:
> What client has -- 1 SQL Server 2000 enterprise Edition running on SQL
> 2003
> NOT clustered, and using a SCSI disk array.
> What client wants -- 2 SQL Server 2005 systems, running on a 2 node
> cluster
> (Active-Passive) using a shared FiberChannel SAN. The active system will
> be
> new, the failover system will be current system listed above. Note that
> Clustering HCL has already been verified.
> Goals -- provide ability to perform a gradual, testable migration from SQL
> Server 2000 to SQL Server 2005 Cluster
> Plan:
> 1) Setup New Server and SAN. Connect Both New server and old server to
> SAN
> 2) Install MS Clustering service on both servers, keeping original
> un-clustered SQL 2000 in production
> 3) Install new instance of SQL 2005 on cluster
> 4) Test and then migrate databases from SQL Server 2000 to new SQL Server
> 2005 cluster one at a time. This means running the non-clustered SQL 2000
> on
> the physical hardware as the clustered SQL 2005 failover node. I realize
> that failover probably wont work well during the transition, due to a lack
> of
> resources.
> 5) When transition is complete, remove SQL Server 2000 from failover
> node.
> Any thoughts or comments would be greatly appreciated.
> Thanks,
> Paul
>
out any potential holes of difficulties with this migration plan:
What client has -- 1 SQL Server 2000 enterprise Edition running on SQL 2003
NOT clustered, and using a SCSI disk array.
What client wants -- 2 SQL Server 2005 systems, running on a 2 node cluster
(Active-Passive) using a shared FiberChannel SAN. The active system will be
new, the failover system will be current system listed above. Note that
Clustering HCL has already been verified.
Goals -- provide ability to perform a gradual, testable migration from SQL
Server 2000 to SQL Server 2005 Cluster
Plan:
1) Setup New Server and SAN. Connect Both New server and old server to SAN
2) Install MS Clustering service on both servers, keeping original
un-clustered SQL 2000 in production
3) Install new instance of SQL 2005 on cluster
4) Test and then migrate databases from SQL Server 2000 to new SQL Server
2005 cluster one at a time. This means running the non-clustered SQL 2000 on
the physical hardware as the clustered SQL 2005 failover node. I realize
that failover probably wont work well during the transition, due to a lack of
resources.
5) When transition is complete, remove SQL Server 2000 from failover node.
Any thoughts or comments would be greatly appreciated.
Thanks,
Paul
My only concern is that you are reusing the existing node as a cluster node.
For simplicity's sake, I would create a a clustered installation without
reusing any of the existing hardware. You then have the original system
completely untouched during the transition. You don't need to connect the
existing SQL server to the SAN to do a minimal down time transfer. Given
proper set up time, I can do a server cutover in less than 15 minutes,
regardless of the total database size or count. Since you are moving one DB
at a time, it even gets easier.
If you have to reuse the existing hardware, I would add it to the cluster
after migration is complete. Install the cluster to a single-node, perform
the migration/cutover, and then reload the OS and add the node to the
cluster. You won't have failover redundancy until the project is complete,
but since you don't have that now, you won't miss it.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"PMartin" <PMartin@.discussions.microsoft.com> wrote in message
news:413AB596-D87F-4EFD-93E3-5335FAC3D647@.microsoft.com...
>I have a fairly unique scenario, and I would like to see if anyone can
>point
> out any potential holes of difficulties with this migration plan:
> What client has -- 1 SQL Server 2000 enterprise Edition running on SQL
> 2003
> NOT clustered, and using a SCSI disk array.
> What client wants -- 2 SQL Server 2005 systems, running on a 2 node
> cluster
> (Active-Passive) using a shared FiberChannel SAN. The active system will
> be
> new, the failover system will be current system listed above. Note that
> Clustering HCL has already been verified.
> Goals -- provide ability to perform a gradual, testable migration from SQL
> Server 2000 to SQL Server 2005 Cluster
> Plan:
> 1) Setup New Server and SAN. Connect Both New server and old server to
> SAN
> 2) Install MS Clustering service on both servers, keeping original
> un-clustered SQL 2000 in production
> 3) Install new instance of SQL 2005 on cluster
> 4) Test and then migrate databases from SQL Server 2000 to new SQL Server
> 2005 cluster one at a time. This means running the non-clustered SQL 2000
> on
> the physical hardware as the clustered SQL 2005 failover node. I realize
> that failover probably wont work well during the transition, due to a lack
> of
> resources.
> 5) When transition is complete, remove SQL Server 2000 from failover
> node.
> Any thoughts or comments would be greatly appreciated.
> Thanks,
> Paul
>
|||Geoff,
Unfortunately, we do need to re-use the hardware, so your suggestion of
installing a single node cluster sounds like oustanding advice. The lack of
failover during the transition will not be critical.
You mentioned reloading the OS on the current (soon to be failover) server.
Is this neceessary with Windows 2003, or just wise a precaution?
Thanks again!
Paul
"Geoff N. Hiten" wrote:
> My only concern is that you are reusing the existing node as a cluster node.
> For simplicity's sake, I would create a a clustered installation without
> reusing any of the existing hardware. You then have the original system
> completely untouched during the transition. You don't need to connect the
> existing SQL server to the SAN to do a minimal down time transfer. Given
> proper set up time, I can do a server cutover in less than 15 minutes,
> regardless of the total database size or count. Since you are moving one DB
> at a time, it even gets easier.
> If you have to reuse the existing hardware, I would add it to the cluster
> after migration is complete. Install the cluster to a single-node, perform
> the migration/cutover, and then reload the OS and add the node to the
> cluster. You won't have failover redundancy until the project is complete,
> but since you don't have that now, you won't miss it.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "PMartin" <PMartin@.discussions.microsoft.com> wrote in message
> news:413AB596-D87F-4EFD-93E3-5335FAC3D647@.microsoft.com...
>
>
|||I have prefer clean OS installs over upgrades. I have never personally had
any problems with 2000-2003 upgrades, but I have had issues with earlier OS
upgrade paths. I have even go so far as to upgrade each node in a cluster
then go back and wipe and reload each node, just so I don't have any
leftover bits. Since you will be migrating a W2000/SQL 2000 standalone host
to a W2003/SQL2005 clustered host, I would definitely wipe the system and
start over. If nothing else, you can guarantee it is an exact OS match for
its peer node.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"PMartin" <PMartin@.discussions.microsoft.com> wrote in message
news:F8076304-BBFE-4447-B0D8-D7A39F0544D4@.microsoft.com...[vbcol=seagreen]
> Geoff,
> Unfortunately, we do need to re-use the hardware, so your suggestion of
> installing a single node cluster sounds like oustanding advice. The lack
> of
> failover during the transition will not be critical.
> You mentioned reloading the OS on the current (soon to be failover)
> server.
> Is this neceessary with Windows 2003, or just wise a precaution?
> Thanks again!
> Paul
> "Geoff N. Hiten" wrote:
|||I don't see anything wrong with this. It's the way that I've upgraded more
than one system already.
Mike
Mentor
Solid Quality Learning
http://www.solidqualitylearning.com
"PMartin" <PMartin@.discussions.microsoft.com> wrote in message
news:413AB596-D87F-4EFD-93E3-5335FAC3D647@.microsoft.com...
>I have a fairly unique scenario, and I would like to see if anyone can
>point
> out any potential holes of difficulties with this migration plan:
> What client has -- 1 SQL Server 2000 enterprise Edition running on SQL
> 2003
> NOT clustered, and using a SCSI disk array.
> What client wants -- 2 SQL Server 2005 systems, running on a 2 node
> cluster
> (Active-Passive) using a shared FiberChannel SAN. The active system will
> be
> new, the failover system will be current system listed above. Note that
> Clustering HCL has already been verified.
> Goals -- provide ability to perform a gradual, testable migration from SQL
> Server 2000 to SQL Server 2005 Cluster
> Plan:
> 1) Setup New Server and SAN. Connect Both New server and old server to
> SAN
> 2) Install MS Clustering service on both servers, keeping original
> un-clustered SQL 2000 in production
> 3) Install new instance of SQL 2005 on cluster
> 4) Test and then migrate databases from SQL Server 2000 to new SQL Server
> 2005 cluster one at a time. This means running the non-clustered SQL 2000
> on
> the physical hardware as the clustered SQL 2005 failover node. I realize
> that failover probably wont work well during the transition, due to a lack
> of
> resources.
> 5) When transition is complete, remove SQL Server 2000 from failover
> node.
> Any thoughts or comments would be greatly appreciated.
> Thanks,
> Paul
>
Subscribe to:
Posts (Atom)