Replication and uniqueidentifier

Abdul,
it's better not to use GUIDs for PKs as they are too
large (4x the size of an integer).
Identity columns can be used in merge replication - you
can enable sql server to maintian the ranges to ensure
they never overlap. Have a look at the article properties
of a table containing identity columns before it is
subscriber to, and there is a checkbox on the identity
range tab. The easiest way is tp ensure that the ranges
are so wide that there will never be any need for them to
be updated.
HTH,
Paul Ibison (SQL Server MVP)[vbcol=seagreen]
Thank you Paul for your reply. I used int primary key to avoid using GUID
because of speed issues but did not foresee that we would use replication
later on. Since there is a limit on using a integer key there is a possiblity
that all the numbers could get taken as there are a lot of rows, and many
rows get inserted daily.
Maybe a string key could work but GUID's are guaranteed to be unique
according to Microsoft. Maybe I can alleviate the speed issue by using a
combination of indexes and selecting only those records which need to be
viewed in the front end. This was the plan but I wanted to make sure that
GUID columns would not be affected when implementing merge replication as I
thought it adds its own guid column.
-Abdul Rauf
"Paul Ibison" wrote:

> Abdul,
> it's better not to use GUIDs for PKs as they are too
> large (4x the size of an integer).
> Identity columns can be used in merge replication - you
> can enable sql server to maintian the ranges to ensure
> they never overlap. Have a look at the article properties
> of a table containing identity columns before it is
> subscriber to, and there is a checkbox on the identity
> range tab. The easiest way is tp ensure that the ranges
> are so wide that there will never be any need for them to
> be updated.
> HTH,
> Paul Ibison (SQL Server MVP)
>
|||Abdul, integers go from -2billion to 2 billion so you're only going to have
a problem if the data spans >4billion!
If that is the case, you could partition the data using a composite key,
with one column as a subscriber identifier.
HTH,
Paul Ibison (SQL Server MVP)[vbcol=seagreen]

replication and datetime columns

I have an interesting server occuring. We have transactional replication running with 1 pub and 6 subscribers. On nearly all the tables we have some sort of date column that's a smalldatetime. If I look at the pub the data will appear like:

2006-11-13 09:59:00

However, on all the subs it appears like:

2006-11-13 09:59:00.000

It's the same column and record but for some reason it's become a datetime. I checked the column types and they are both smalldatetime's.

Why is this happening? What can be done?

Thanks,

Phil

I am unable to repro this on my SQL 2000 and SQL 2005 servers. What version of SQL Server are you running and what SPs?|||

Actually I found the problem. It looks as if when you use the four part name server.db.dbo.tablename from the publisher that the column "appears" to be a datetime. When I actually go to the server and select it.. then it's the normal smalldatetime. I don't know if this has something to do w/ ODBC connection accross linked servers or what...

Thanks,

Phil

Replicating Table

How do I write a SQL statement that can replicate table without specifying
the data columns? For example, I have Table A with 12 columns, and I want to
create Table B with exactly the same fields and data type. Is there an easy
way out?I believe you just want to copy the data with the same datatypes.
You could try this
SELECT * INTO NewTabel1 from OldTable1
But this will not copy Keys/Contraints/Defaults...
- Sha Anand
"wrytat" wrote:

> How do I write a SQL statement that can replicate table without specifying
> the data columns? For example, I have Table A with 12 columns, and I want
to
> create Table B with exactly the same fields and data type. Is there an eas
y
> way out?|||And if you don't want the data and just the structure.
then use this...
SELECT * INTO NewTabel1 from OldTable1 where 1 = 0|||Thank you for helping.
"Omnibuzz" wrote:

> And if you don't want the data and just the structure.
> then use this...
> SELECT * INTO NewTabel1 from OldTable1 where 1 = 0
>