Please help ...

Hello,

Could somebody please tell me , how to export stored procedure data to EXCEL using DTS ?

Please advice me!Your stored procedure is probably returning a a set of records?

In that case, just take the query in your storder proc and create a DTS job to run that query into an excel file. If you need to then be able to kick off that job at will, you can use the DTSRUN utility from a stored procedure to start it.

If you need to send variables to the DTS job so that it can dynamically select only certain records, you can pass parameters to a stored procedure and then use techniques discussed here:

http://www.databasejournal.com/features/mssql/article.php/1461481
http://www.databasejournal.com/features/mssql/article.php/1462571

You were a little sketchy on what you need to do.

Please advise!

Hi there!!

I just want to ask one question and i am looking for advice or recommendation.

I want to make an application using windows application in .NET. this application is only to have one or two users to enter details of clients on the database using the application and it will be a search for client name or number and other search methods which is similar.

My question now, what database shall i use for this kind of application SQL server or MS Access. i am looking for a new product to use as the cleint can not afford expensive software. Please advise!! thanks!!What about the free version of MS SQL Server (called MSDE)?

Functionaly it's the same as regular SQL Server, but with some performance restrictions (not intended for large number of users) and does not come with Enterprise Manager.

http://msdn.microsoft.com/sql/msde/msde/default.aspx

Cheers...|||... or the SQL 2005 EXPRESS edition which is a free download from MS. It's the full monty apart from enterprise-level features, and it's restricted to 1 processor and a 4Gb database, but it is free and will integrate fully with VS.NET 2005.|||Hi !!

Thank you all for your reply !!!

Just Three questions:-

1) As the application that i iw ill write will be for commercial use, can i use the software free and no license is required to pay for?

2) i use VS.NET 2003, will that be ok?

3) CAn the suggested versions of the SQL Server hold a large number of data? and is it easy in the future to convert to a better versions with transfer all the data from old to new version (in case it is needed in the future)?

Thank you again for your help, and i wish you can advise more!!!sql

Please Advice !

Hi,

I am trying to solve this procedure.

Let me try to explain it...I am getting DEGREEID from one of the SELECT query . I want to OUTPUT (ie , COUNT) from procedure,the number of departments with the degreeid, got from the above query.

With below procedure, Since an employee can have multiple DEGREEID , the cursor is giving OUPTUT ie, COUNT for the LAST Degreeid. Eventhough the previous DEGREEID dont have any DEPARTMENT...but only for the LAST DEGREEID...!

How can I solve this.... whether I can solve this with CURSOR or I have to use someother way...Please advice me !

DATA
---
DEGREE_EARNED
-------
EMPID DEGREEID
-- ----
201 12
201 3
201 250
202 3
202 10
203 17

DEPARTMENT
-----
DEPID DEGREEID
-- ----
10 1 12
111 250
111 12
121 3
121 12
121 250
-----------



---------------------
DECLARE @.vchid int
DECLARE testcursor CURSOR FOR

SELECT degree_id
FROM degree_earned WHERE emp_id= @.empid

OPEN testcursor
FETCH NEXT FROM testcursor INTO @.vchid

WHILE (@.@.FETCH_STATUS <> -1)

BEGIN
Select @.outresult = COUNT(*)
from
department
where degree_id = @.vchid

FETCH NEXT FROM testcursor INTO @.vchid
END
---------------------Can somebody help me,please (:|||So is what you want something like:EMPID DEGREEID DEPT_COUNT
-- --- ----
201 12 2
201 3 1
201 250 2
202 3 1
202 10 0
203 17 0I don't understand exactly what you want, so I can't be much help until I do. Sorry!

-PatP|||Hey Pat,

Thats what i wanted...Can u please show me , how to solve this...Thanks!|||USE Northwind
GO

CREATE TABLE DEGREE_EARNED(EMPID int, DEGREEID int)
CREATE TABLE DEPARTMENT(DEPID int, DEGREEID int)
GO
INSERT INTO DEGREE_EARNED(EMPID, DEGREEID)
SELECT 201, 12 UNION ALL
SELECT 201, 3 UNION ALL
SELECT 201, 250 UNION ALL
SELECT 202, 3 UNION ALL
SELECT 202, 10 UNION ALL
SELECT 203, 17

INSERT INTO DEPARTMENT(DEPID, DEGREEID)
SELECT 101, 12 UNION ALL
SELECT 111, 250 UNION ALL
SELECT 111, 12 UNION ALL
SELECT 121, 3 UNION ALL
SELECT 121, 12 UNION ALL
SELECT 121, 250
GO

SELECT A.DEGREEID, ISNULL(ROW_OCCURS,0)
FROM ( SELECT DISTINCT DEGREEID FROM DEGREE_EARNED) AS A
LEFT JOIN ( SELECT DEGREEID, COUNT(*) AS ROW_OCCURS
FROM DEPARTMENT GROUP BY DEGREEID) AS B
ON A.DEGREEID = B.DEGREEID
GO

--DROP TABLE DEGREE_EARNED
--DROP TABLE DEPARTMENT
GOsql

PK Generation Or Data Synchronization - Repost

Sorry for repost, but there was a problem with my MSDN posting alias.
I would appreciate some advice on generating a PK and/or synchronizing data
between two (maybe three) locations.
Simplified scenario.
Using SQL Server 2005 (could got to 2008 if needed).
Client has two locations (central and remote).
Item record would containseven fields - six int fields (id's from component
tables) and a seventh field that would be the PK.
Most of the time the PK would be generated at central, however, should the
connection be lost, remote must be able to generate a PK also and then when
connection is restored, any new PK generated by remote must be added to
central.
The PK needs to be the same for the same combination of the six fields, no
matter which server generated it, in case both servers happened to create a
record with the same six fields. Therefore using a GUID would not work.
Since the PK will be used by another system (Great Plains), it's length is
limited to 30 characters.
I am hoping for some algorathym that would combine the six column values
and always generate the same value from the same six values. Something like
a hash code. However, I am limited to 30 characters and I do believe a hash
code is 64.
Another idea is to write routines to do the 'replication', instead of using
SQL replication.
Then add all new rows in 'remote' via a stored procedure. If the sp can't
connect to 'central' it would generate it's own PK and also record that in
another table. Then when connectivity is restored, my replication routine
would check for duplicate rows and if necessary, update the PK in 'remote'
with the PK from 'central'.
Aside from the complexity, the problem with that is I don't know if Great
Plains can use cascade update to update its' detail tables that would be
referencing my PK as an FK.
--
AG
Email: discussATadhdataDOTcomHi AG,
Appreciate your understanding that this is not a dedicated SQL Server
related question. Regarding such algorithm related consulting question, I
am afraid that we could only give you some general suggestions here. For
your requirements, I think that it is better to use cryptographic hash
function to generate PK. Though the output length is 64, you can just
retrieve the first 30 bytes. I think that the opportunity of retrieving
same PK value is also very rare. You know that GUID is just a 16 byte
value, however you are getting a 30 byte value from the hash code. You may
perform a test to insert 1 million rows to your table to see if there are
any duplicated PK values generated.
Please feel free to let me know if you have any other questions or
concerns. Have a nice day!
Best regards,
Charles Wang
Microsoft Online Community Support
===========================================================Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg@.microsoft.com.
===========================================================Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for
non-urgent issues where an initial response from the community
or a Microsoft Support Engineer within 1 business day is acceptable.
Please note that each follow up response may take approximately
2 business days as the support professional working with you may
need further investigation to reach the most efficient resolution.
The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by
contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
============================================================This posting is provided "AS IS" with no warranties, and confers no rights.
=========================================================|||Thanks for the reply Charles.
I did not expect someone to write an algorithm for me. Although if someone
already had something similar and wanted to share, that would be great.
I understand about GUID, but the problem is that, should each server
generate a new PK for the same combination of the six fields, I would want
the PK generated to be the same.
Using the hash, are you saying that it is extremely likely for the first 30
bytes to be unique and to use the million row test to confirm that?
I guess the main question here is, what do others do in similar situation? I
can't believe that this situation is so uncommon.
--
AG
Email: discussATadhdataDOTcom
"Charles Wang[MSFT]" <changliw@.online.microsoft.com> wrote in message
news:ManMJWMlIHA.3756@.TK2MSFTNGHUB02.phx.gbl...
> Hi AG,
> Appreciate your understanding that this is not a dedicated SQL Server
> related question. Regarding such algorithm related consulting question, I
> am afraid that we could only give you some general suggestions here. For
> your requirements, I think that it is better to use cryptographic hash
> function to generate PK. Though the output length is 64, you can just
> retrieve the first 30 bytes. I think that the opportunity of retrieving
> same PK value is also very rare. You know that GUID is just a 16 byte
> value, however you are getting a 30 byte value from the hash code. You may
> perform a test to insert 1 million rows to your table to see if there are
> any duplicated PK values generated.
> Please feel free to let me know if you have any other questions or
> concerns. Have a nice day!
> Best regards,
> Charles Wang
> Microsoft Online Community Support
> ===========================================================> Delighting our customers is our #1 priority. We welcome your
> comments and suggestions about how we can improve the
> support we provide to you. Please feel free to let my manager
> know what you think of the level of service provided. You can
> send feedback directly to my manager at: msdnmg@.microsoft.com.
> ===========================================================> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> ications.
> Note: The MSDN Managed Newsgroup support offering is for
> non-urgent issues where an initial response from the community
> or a Microsoft Support Engineer within 1 business day is acceptable.
> Please note that each follow up response may take approximately
> 2 business days as the support professional working with you may
> need further investigation to reach the most efficient resolution.
> The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by
> contacting Microsoft Customer Support Services (CSS) at
> http://msdn.microsoft.com/subscriptions/support/default.aspx.
> ============================================================> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> =========================================================>|||Hi AG,
> Using the hash, are you saying that it is extremely likely for the first
30
> bytes to be unique and to use the million row test to confirm that?
Yes, I think so. You may use .NET to develop a CLR stored procedure or user
function to generate a hash code or you may use third party extended stored
procedures like this:
MD5 Hash SQL Server Extended Stored Procedure
http://www.codeproject.com/KB/database/xp_md5.aspx
Best regards,
Charles Wang
Microsoft Online Community Support
=========================================================Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg@.microsoft.com.
=========================================================This posting is provided "AS IS" with no warranties, and confers no rights.
=========================================================|||Thanks Charles, I will give that a try.
How about responding to my last question/comment?
What do others do in similar situation?
I can't believe that this situation is so uncommon.
--
AG
Email: discussATadhdataDOTcom
"Charles Wang[MSFT]" <changliw@.online.microsoft.com> wrote in message
news:EPjgFQXlIHA.3756@.TK2MSFTNGHUB02.phx.gbl...
> Hi AG,
>> Using the hash, are you saying that it is extremely likely for the first
> 30
>> bytes to be unique and to use the million row test to confirm that?
> Yes, I think so. You may use .NET to develop a CLR stored procedure or
> user
> function to generate a hash code or you may use third party extended
> stored
> procedures like this:
> MD5 Hash SQL Server Extended Stored Procedure
> http://www.codeproject.com/KB/database/xp_md5.aspx
> Best regards,
> Charles Wang
> Microsoft Online Community Support
> =========================================================> Delighting our customers is our #1 priority. We welcome your
> comments and suggestions about how we can improve the
> support we provide to you. Please feel free to let my manager
> know what you think of the level of service provided. You can
> send feedback directly to my manager at: msdnmg@.microsoft.com.
> =========================================================> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> =========================================================>|||Hi AG,
Honestly I did not see others having such requirements before. For most
cases, you can use SQL Server replication to replicate data among different
servers. If you want high availability, you can use SQL failover cluster or
Database Mirroring? Since there is failover function on SQL Server Failover
cluster and Database Mirroring, the data consistency can be ensured on
different servers. It seems that your requirements can be fitted by using
SQL Server failover cluster or Database Mirroring (only for SQL Server 2005
or 2008).
You may refer to:
SQL Server 2005 Failover Clustering White Paper
http://www.microsoft.com/downloads/details.aspx?FamilyID=818234dc-a17b-4f09-
b282-c6830fead499&displaylang=en
Database Mirroring in SQL Server 2005
http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirror.mspx
Please feel free to let me know if you have any other questions or
concerns. Have a nice day!
Best regards,
Charles Wang
Microsoft Online Community Support
=========================================================Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg@.microsoft.com.
=========================================================This posting is provided "AS IS" with no warranties, and confers no rights.
=========================================================|||Thanks, I will check those out.
--
AG
Email: discussATadhdataDOTcom
"Charles Wang[MSFT]" <changliw@.online.microsoft.com> wrote in message
news:qq9FvrhlIHA.7196@.TK2MSFTNGHUB02.phx.gbl...
> Hi AG,
> Honestly I did not see others having such requirements before. For most
> cases, you can use SQL Server replication to replicate data among
> different
> servers. If you want high availability, you can use SQL failover cluster
> or
> Database Mirroring? Since there is failover function on SQL Server
> Failover
> cluster and Database Mirroring, the data consistency can be ensured on
> different servers. It seems that your requirements can be fitted by using
> SQL Server failover cluster or Database Mirroring (only for SQL Server
> 2005
> or 2008).
> You may refer to:
> SQL Server 2005 Failover Clustering White Paper
> http://www.microsoft.com/downloads/details.aspx?FamilyID=818234dc-a17b-4f09-
> b282-c6830fead499&displaylang=en
> Database Mirroring in SQL Server 2005
> http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirror.mspx
> Please feel free to let me know if you have any other questions or
> concerns. Have a nice day!
> Best regards,
> Charles Wang
> Microsoft Online Community Support
> =========================================================> Delighting our customers is our #1 priority. We welcome your
> comments and suggestions about how we can improve the
> support we provide to you. Please feel free to let my manager
> know what you think of the level of service provided. You can
> send feedback directly to my manager at: msdnmg@.microsoft.com.
> =========================================================> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> =========================================================>

PK Generation Or Data Synchronization - Repost

Sorry for repost, but there was a problem with my MSDN posting alias.
I would appreciate some advice on generating a PK and/or synchronizing data
between two (maybe three) locations.
Simplified scenario.
Using SQL Server 2005 (could got to 2008 if needed).
Client has two locations (central and remote).
Item record would containseven fields - six int fields (id's from component
tables) and a seventh field that would be the PK.
Most of the time the PK would be generated at central, however, should the
connection be lost, remote must be able to generate a PK also and then when
connection is restored, any new PK generated by remote must be added to
central.
The PK needs to be the same for the same combination of the six fields, no
matter which server generated it, in case both servers happened to create a
record with the same six fields. Therefore using a GUID would not work.
Since the PK will be used by another system (Great Plains), it's length is
limited to 30 characters.
I am hoping for some algorathym that would combine the six column values
and always generate the same value from the same six values. Something like
a hash code. However, I am limited to 30 characters and I do believe a hash
code is 64.
Another idea is to write routines to do the 'replication', instead of using
SQL replication.
Then add all new rows in 'remote' via a stored procedure. If the sp can't
connect to 'central' it would generate it's own PK and also record that in
another table. Then when connectivity is restored, my replication routine
would check for duplicate rows and if necessary, update the PK in 'remote'
with the PK from 'central'.
Aside from the complexity, the problem with that is I don't know if Great
Plains can use cascade update to update its' detail tables that would be
referencing my PK as an FK.

AG
Email: discussATadhdataDOTcom
Hi AG,
Appreciate your understanding that this is not a dedicated SQL Server
related question. Regarding such algorithm related consulting question, I
am afraid that we could only give you some general suggestions here. For
your requirements, I think that it is better to use cryptographic hash
function to generate PK. Though the output length is 64, you can just
retrieve the first 30 bytes. I think that the opportunity of retrieving
same PK value is also very rare. You know that GUID is just a 16 byte
value, however you are getting a 30 byte value from the hash code. You may
perform a test to insert 1 million rows to your table to see if there are
any duplicated PK values generated.
Please feel free to let me know if you have any other questions or
concerns. Have a nice day!
Best regards,
Charles Wang
Microsoft Online Community Support
================================================== =========
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg@.microsoft.com.
================================================== =========
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for
non-urgent issues where an initial response from the community
or a Microsoft Support Engineer within 1 business day is acceptable.
Please note that each follow up response may take approximately
2 business days as the support professional working with you may
need further investigation to reach the most efficient resolution.
The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by
contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
================================================== ==========
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== =======
|||Thanks for the reply Charles.
I did not expect someone to write an algorithm for me. Although if someone
already had something similar and wanted to share, that would be great.
I understand about GUID, but the problem is that, should each server
generate a new PK for the same combination of the six fields, I would want
the PK generated to be the same.
Using the hash, are you saying that it is extremely likely for the first 30
bytes to be unique and to use the million row test to confirm that?
I guess the main question here is, what do others do in similar situation? I
can't believe that this situation is so uncommon.
AG
Email: discussATadhdataDOTcom
"Charles Wang[MSFT]" <changliw@.online.microsoft.com> wrote in message
news:ManMJWMlIHA.3756@.TK2MSFTNGHUB02.phx.gbl...
> Hi AG,
> Appreciate your understanding that this is not a dedicated SQL Server
> related question. Regarding such algorithm related consulting question, I
> am afraid that we could only give you some general suggestions here. For
> your requirements, I think that it is better to use cryptographic hash
> function to generate PK. Though the output length is 64, you can just
> retrieve the first 30 bytes. I think that the opportunity of retrieving
> same PK value is also very rare. You know that GUID is just a 16 byte
> value, however you are getting a 30 byte value from the hash code. You may
> perform a test to insert 1 million rows to your table to see if there are
> any duplicated PK values generated.
> Please feel free to let me know if you have any other questions or
> concerns. Have a nice day!
> Best regards,
> Charles Wang
> Microsoft Online Community Support
> ================================================== =========
> Delighting our customers is our #1 priority. We welcome your
> comments and suggestions about how we can improve the
> support we provide to you. Please feel free to let my manager
> know what you think of the level of service provided. You can
> send feedback directly to my manager at: msdnmg@.microsoft.com.
> ================================================== =========
> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> ications.
> Note: The MSDN Managed Newsgroup support offering is for
> non-urgent issues where an initial response from the community
> or a Microsoft Support Engineer within 1 business day is acceptable.
> Please note that each follow up response may take approximately
> 2 business days as the support professional working with you may
> need further investigation to reach the most efficient resolution.
> The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by
> contacting Microsoft Customer Support Services (CSS) at
> http://msdn.microsoft.com/subscriptions/support/default.aspx.
> ================================================== ==========
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> ================================================== =======
>
|||Hi AG,
> Using the hash, are you saying that it is extremely likely for the first
30
> bytes to be unique and to use the million row test to confirm that?
Yes, I think so. You may use .NET to develop a CLR stored procedure or user
function to generate a hash code or you may use third party extended stored
procedures like this:
MD5 Hash SQL Server Extended Stored Procedure
http://www.codeproject.com/KB/database/xp_md5.aspx
Best regards,
Charles Wang
Microsoft Online Community Support
================================================== =======
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg@.microsoft.com.
================================================== =======
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== =======
|||Thanks Charles, I will give that a try.
How about responding to my last question/comment?
What do others do in similar situation?
I can't believe that this situation is so uncommon.
AG
Email: discussATadhdataDOTcom
"Charles Wang[MSFT]" <changliw@.online.microsoft.com> wrote in message
news:EPjgFQXlIHA.3756@.TK2MSFTNGHUB02.phx.gbl...
> Hi AG,
> 30
> Yes, I think so. You may use .NET to develop a CLR stored procedure or
> user
> function to generate a hash code or you may use third party extended
> stored
> procedures like this:
> MD5 Hash SQL Server Extended Stored Procedure
> http://www.codeproject.com/KB/database/xp_md5.aspx
> Best regards,
> Charles Wang
> Microsoft Online Community Support
> ================================================== =======
> Delighting our customers is our #1 priority. We welcome your
> comments and suggestions about how we can improve the
> support we provide to you. Please feel free to let my manager
> know what you think of the level of service provided. You can
> send feedback directly to my manager at: msdnmg@.microsoft.com.
> ================================================== =======
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> ================================================== =======
>
|||Hi AG,
Honestly I did not see others having such requirements before. For most
cases, you can use SQL Server replication to replicate data among different
servers. If you want high availability, you can use SQL failover cluster or
Database Mirroring? Since there is failover function on SQL Server Failover
cluster and Database Mirroring, the data consistency can be ensured on
different servers. It seems that your requirements can be fitted by using
SQL Server failover cluster or Database Mirroring (only for SQL Server 2005
or 2008).
You may refer to:
SQL Server 2005 Failover Clustering White Paper
http://www.microsoft.com/downloads/details.aspx?FamilyID=818234dc-a17b-4f09-
b282-c6830fead499&displaylang=en
Database Mirroring in SQL Server 2005
http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirror.mspx
Please feel free to let me know if you have any other questions or
concerns. Have a nice day!
Best regards,
Charles Wang
Microsoft Online Community Support
================================================== =======
Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg@.microsoft.com.
================================================== =======
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== =======
|||Thanks, I will check those out.
AG
Email: discussATadhdataDOTcom
"Charles Wang[MSFT]" <changliw@.online.microsoft.com> wrote in message
news:qq9FvrhlIHA.7196@.TK2MSFTNGHUB02.phx.gbl...
> Hi AG,
> Honestly I did not see others having such requirements before. For most
> cases, you can use SQL Server replication to replicate data among
> different
> servers. If you want high availability, you can use SQL failover cluster
> or
> Database Mirroring? Since there is failover function on SQL Server
> Failover
> cluster and Database Mirroring, the data consistency can be ensured on
> different servers. It seems that your requirements can be fitted by using
> SQL Server failover cluster or Database Mirroring (only for SQL Server
> 2005
> or 2008).
> You may refer to:
> SQL Server 2005 Failover Clustering White Paper
> http://www.microsoft.com/downloads/details.aspx?FamilyID=818234dc-a17b-4f09-
> b282-c6830fead499&displaylang=en
> Database Mirroring in SQL Server 2005
> http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirror.mspx
> Please feel free to let me know if you have any other questions or
> concerns. Have a nice day!
> Best regards,
> Charles Wang
> Microsoft Online Community Support
> ================================================== =======
> Delighting our customers is our #1 priority. We welcome your
> comments and suggestions about how we can improve the
> support we provide to you. Please feel free to let my manager
> know what you think of the level of service provided. You can
> send feedback directly to my manager at: msdnmg@.microsoft.com.
> ================================================== =======
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> ================================================== =======
>

PK Generation Or Data Synchronization

I would appreciate some advice on generating a PK and/or synchronizing data
between two (maybe three) locations.
Simplified scenario.
Using SQL Server 2005 (could got to 2008 if needed).
Client has two locations (central and remote).
Item record would containseven fields - six int fields (id's from component
tables) and a seventh field that would be the PK.
Most of the time the PK would be generated at central, however, should the
connection be lost, remote must be able to generate a PK also and then when
connection is restored, any new PK generated by remote must be added to
central.
The PK needs to be the same for the same combination of the six fields, no
matter which server generated it, in case both servers happened to create a
record with the same six fields. Therefore using a GUID would not work.
Since the PK will be used by another system (Great Plains), it's length is
limited to 30 characters.
AG
Email: discussATadhdataDOTcom
Well you could simply use a coded IDENTITY or similar. By coded, I mean
generating the new ID in a central table, and on each server the identity
seed is different, e.g. on central it starts at 1, on remote it starts at
something like 2000000 or some reasonably large number that you won't get to
in central. INTs are big and BIGINTs are bigger; for the latter you could
spread the numbers out over a million servers and still have plenty of room
to grow for just about any business model. In addition to ensuring
uniqueness, this way when you replicate data back to central, you know which
rows were created on the remote system (which a GUID wouldn't tell you).
However, now that I mention GUID, I am thinking about one of your final
comments. If the systems cannot talk to each other, and regardless of what
methodology you use for your surrogate key, what are you going to do to
consolidate when the remote server creates a new row where the six columns
are the same as a row that already exists in the central database? (Even if
you are using replication, let's say that row was created just before the
server went down, and the row was never copied to remote.) You can't
prevent the new row from being inserted, because you don't know such a row
already exists!
"AG" <NOSPAMa-giam@.newsgroups.nospam> wrote in message
news:uxVTMTHkIHA.5724@.TK2MSFTNGP03.phx.gbl...
>I would appreciate some advice on generating a PK and/or synchronizing data
>between two (maybe three) locations.
> Simplified scenario.
> Using SQL Server 2005 (could got to 2008 if needed).
> Client has two locations (central and remote).
> Item record would containseven fields - six int fields (id's from
> component tables) and a seventh field that would be the PK.
> Most of the time the PK would be generated at central, however, should the
> connection be lost, remote must be able to generate a PK also and then
> when connection is restored, any new PK generated by remote must be added
> to central.
> The PK needs to be the same for the same combination of the six fields, no
> matter which server generated it, in case both servers happened to create
> a record with the same six fields. Therefore using a GUID would not work.
> Since the PK will be used by another system (Great Plains), it's length is
> limited to 30 characters.
> --
> AG
> Email: discussATadhdataDOTcom
>
|||Thanks for the quick reply Aaron.
I had thought about a GUID also. As well as generating the PK in a trigger
using odd numbers for one server and even for another, but your idea of a
different identity seed is simpler and more scalable.
However, as you stated also, the problem is that there could be the same six
columns with different PK's generated by both servers when connection is
down.
I was hoping for some algorathym that would combine the six column values
and always generate the same value from the same six values. Something like
a hash code. However, I am limited to 30 characters and I do believe a hash
code is 64.
Another idea is to write routines to do the 'replication', instead of using
SQL replication.
Then add all new rows in 'remote' via a stored procedure. If the sp can't
connect to 'central' it would generate it's own PK and also record that in
another table. Then when connectivity is restored, my replication routine
would check for duplicate rows and if necessary, update the PK in 'remote'
with the PK from 'central'.
Aside from the complexity, the problem with that is I don't know if Great
Plains can use cascade update to update its' detail tables that would be
referencing my PK as an FK.
AG
Email: discussATadhdataDOTcom
"Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:2BD5421B-65B2-4B86-8080-015FC8A50740@.microsoft.com...
> Well you could simply use a coded IDENTITY or similar. By coded, I mean
> generating the new ID in a central table, and on each server the identity
> seed is different, e.g. on central it starts at 1, on remote it starts at
> something like 2000000 or some reasonably large number that you won't get
> to in central. INTs are big and BIGINTs are bigger; for the latter you
> could spread the numbers out over a million servers and still have plenty
> of room to grow for just about any business model. In addition to
> ensuring uniqueness, this way when you replicate data back to central, you
> know which rows were created on the remote system (which a GUID wouldn't
> tell you).
> However, now that I mention GUID, I am thinking about one of your final
> comments. If the systems cannot talk to each other, and regardless of
> what methodology you use for your surrogate key, what are you going to do
> to consolidate when the remote server creates a new row where the six
> columns are the same as a row that already exists in the central database?
> (Even if you are using replication, let's say that row was created just
> before the server went down, and the row was never copied to remote.) You
> can't prevent the new row from being inserted, because you don't know such
> a row already exists!
>
>
> "AG" <NOSPAMa-giam@.newsgroups.nospam> wrote in message
> news:uxVTMTHkIHA.5724@.TK2MSFTNGP03.phx.gbl...
>

PK Generation Or Data Synchronization

I would appreciate some advice on generating a PK and/or synchronizing data
between two (maybe three) locations.
Simplified scenario.
Using SQL Server 2005 (could got to 2008 if needed).
Client has two locations (central and remote).
Item record would containseven fields - six int fields (id's from component
tables) and a seventh field that would be the PK.
Most of the time the PK would be generated at central, however, should the
connection be lost, remote must be able to generate a PK also and then when
connection is restored, any new PK generated by remote must be added to
central.
The PK needs to be the same for the same combination of the six fields, no
matter which server generated it, in case both servers happened to create a
record with the same six fields. Therefore using a GUID would not work.
Since the PK will be used by another system (Great Plains), it's length is
limited to 30 characters.
--
AG
Email: discussATadhdataDOTcomWell you could simply use a coded IDENTITY or similar. By coded, I mean
generating the new ID in a central table, and on each server the identity
seed is different, e.g. on central it starts at 1, on remote it starts at
something like 2000000 or some reasonably large number that you won't get to
in central. INTs are big and BIGINTs are bigger; for the latter you could
spread the numbers out over a million servers and still have plenty of room
to grow for just about any business model. In addition to ensuring
uniqueness, this way when you replicate data back to central, you know which
rows were created on the remote system (which a GUID wouldn't tell you).
However, now that I mention GUID, I am thinking about one of your final
comments. If the systems cannot talk to each other, and regardless of what
methodology you use for your surrogate key, what are you going to do to
consolidate when the remote server creates a new row where the six columns
are the same as a row that already exists in the central database? (Even if
you are using replication, let's say that row was created just before the
server went down, and the row was never copied to remote.) You can't
prevent the new row from being inserted, because you don't know such a row
already exists!
"AG" <NOSPAMa-giam@.newsgroups.nospam> wrote in message
news:uxVTMTHkIHA.5724@.TK2MSFTNGP03.phx.gbl...
>I would appreciate some advice on generating a PK and/or synchronizing data
>between two (maybe three) locations.
> Simplified scenario.
> Using SQL Server 2005 (could got to 2008 if needed).
> Client has two locations (central and remote).
> Item record would containseven fields - six int fields (id's from
> component tables) and a seventh field that would be the PK.
> Most of the time the PK would be generated at central, however, should the
> connection be lost, remote must be able to generate a PK also and then
> when connection is restored, any new PK generated by remote must be added
> to central.
> The PK needs to be the same for the same combination of the six fields, no
> matter which server generated it, in case both servers happened to create
> a record with the same six fields. Therefore using a GUID would not work.
> Since the PK will be used by another system (Great Plains), it's length is
> limited to 30 characters.
> --
> AG
> Email: discussATadhdataDOTcom
>|||Thanks for the quick reply Aaron.
I had thought about a GUID also. As well as generating the PK in a trigger
using odd numbers for one server and even for another, but your idea of a
different identity seed is simpler and more scalable.
However, as you stated also, the problem is that there could be the same six
columns with different PK's generated by both servers when connection is
down.
I was hoping for some algorathym that would combine the six column values
and always generate the same value from the same six values. Something like
a hash code. However, I am limited to 30 characters and I do believe a hash
code is 64.
Another idea is to write routines to do the 'replication', instead of using
SQL replication.
Then add all new rows in 'remote' via a stored procedure. If the sp can't
connect to 'central' it would generate it's own PK and also record that in
another table. Then when connectivity is restored, my replication routine
would check for duplicate rows and if necessary, update the PK in 'remote'
with the PK from 'central'.
Aside from the complexity, the problem with that is I don't know if Great
Plains can use cascade update to update its' detail tables that would be
referencing my PK as an FK.
--
AG
Email: discussATadhdataDOTcom
"Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:2BD5421B-65B2-4B86-8080-015FC8A50740@.microsoft.com...
> Well you could simply use a coded IDENTITY or similar. By coded, I mean
> generating the new ID in a central table, and on each server the identity
> seed is different, e.g. on central it starts at 1, on remote it starts at
> something like 2000000 or some reasonably large number that you won't get
> to in central. INTs are big and BIGINTs are bigger; for the latter you
> could spread the numbers out over a million servers and still have plenty
> of room to grow for just about any business model. In addition to
> ensuring uniqueness, this way when you replicate data back to central, you
> know which rows were created on the remote system (which a GUID wouldn't
> tell you).
> However, now that I mention GUID, I am thinking about one of your final
> comments. If the systems cannot talk to each other, and regardless of
> what methodology you use for your surrogate key, what are you going to do
> to consolidate when the remote server creates a new row where the six
> columns are the same as a row that already exists in the central database?
> (Even if you are using replication, let's say that row was created just
> before the server went down, and the row was never copied to remote.) You
> can't prevent the new row from being inserted, because you don't know such
> a row already exists!
>
>
> "AG" <NOSPAMa-giam@.newsgroups.nospam> wrote in message
> news:uxVTMTHkIHA.5724@.TK2MSFTNGP03.phx.gbl...
>>I would appreciate some advice on generating a PK and/or synchronizing
>>data between two (maybe three) locations.
>> Simplified scenario.
>> Using SQL Server 2005 (could got to 2008 if needed).
>> Client has two locations (central and remote).
>> Item record would containseven fields - six int fields (id's from
>> component tables) and a seventh field that would be the PK.
>> Most of the time the PK would be generated at central, however, should
>> the connection be lost, remote must be able to generate a PK also and
>> then when connection is restored, any new PK generated by remote must be
>> added to central.
>> The PK needs to be the same for the same combination of the six fields,
>> no matter which server generated it, in case both servers happened to
>> create a record with the same six fields. Therefore using a GUID would
>> not work.
>> Since the PK will be used by another system (Great Plains), it's length
>> is limited to 30 characters.
>> --
>> AG
>> Email: discussATadhdataDOTcom
>