Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Identity Vs. Uniqueidentifier (Newbie question)

12,047 views
Skip to first unread message

Bob

unread,
Jan 31, 2001, 2:13:43 PM1/31/01
to
Would any one care to explore the pros & cons of using Identity numbers Vs.
The uniqueidentifier in SQL2000?


lindawie

unread,
Jan 31, 2001, 2:39:54 PM1/31/01
to
Bob,

I always use a long integer for identity columns. A long integer has the
advantage that it is the native data type of the operating system.
Operations on integral data both in SQL and in client-side languages will be
fast, and integers are easy to work with in any language. An Identity
column is not updateable. SQL Server will raise an error if you try to
update it. I see this as an advantage and safeguard because I do not permit
updateable primary keys in my databases and I it save me work when SQL
Server enforces this for me.

The drawback of an integer identity value is that it only unique within a
single table. Any data consolidation operations become more complex because
new surrogate key values need to be generated as data is imported. The
current identity value can be reset using DBCC. This can be a problem for
applications that do not enforce referential integrity and allow
indiscriminate delete activity on tables.


A unique identifier has the advantage that it is unique in time and space.
This is a highly desirable data attribute for data warehousing operations,
distributed databases, or any other application where data from various
sources needs to be consolidated into a single table.

The drawback is that guid values are hard to look at and sometimes hard to
work with. Not every client-side language provides direct support for a
guid data type, so workarounds may be needed. Uniqueidentifier columns are
updateable, what I consider to be a drawback, because I need to write extra
code to prevent this from happening.

The mac address is embedded in the guid, so depending on your point of view,
this is an advantage or a drawback. Theoretically an instance of data could
be traced back to its machine of origin. It could be argued that this as
nice control mechanism or a privacy issue.


Linda

"Bob" <bil...@holt.k12.mi.us> wrote in message
news:#A77Ss7iAHA.2076@tkmsftngp03...

Tony Rogerson

unread,
Jan 31, 2001, 2:50:19 PM1/31/01
to microsoft.public.sqlserver.programming
If you need uniqueness across servers or are using merge replication then
I'd strongly consider using a uniqueidentifier.

For ease of programming I'd use identity.

The difference between them is that the identity is incremental, so, in a
trading system for instance inserted rows would be grouped together in the
table giving rise to less IO (less page reads) to query recent date - ok,
you'd have a trade date as well -it's just to illustrate it. The
uniqueidentifier on the other hand when used with NEWID() gives a random
binary value, so your data will be randomly spread across the table.

This assumes of course you don't cluster on something useful like a
tradedate or something...

--
Tony Rogerson SQL Server MVP
Torver Computer Consultants Ltd
www.sql-server.co.uk [UK SQL Server User Group - FAQ, SQL Tutorials etc...]


"Bob" <bil...@holt.k12.mi.us> wrote in message
news:#A77Ss7iAHA.2076@tkmsftngp03...

Joe Celko

unread,
Jan 31, 2001, 2:57:04 PM1/31/01
to

>> Would any one care to explore the pros & cons of using Identity
numbers versus the uniqueidentifier in SQL2000? <<

Welcome to a religious war <g>! I stand on the side of relational
purity, good data modeling and all that is Holy. My opponents, who I
am sure will drawn here shortly, are in league with the Forces of
Darkness <g>.

Real SQL programmers use real keys and do not try to imitate 1950's
magnetic tape or punch card systems in a relational model. In the
early days of programming languages, we exposed a lot of the physical
and hardware implementation to the programmer. For example, COBOL and
FORTRAN depend on physically contiguous storage of data, which made a
ROWID (i.e. physical location reference) possible.

Later, we designed languages to independent of any physical and
hardware implementation. Thus, an INTEGER datatype did not have to be
eight binary bits in a two complement format. It just had to behave
like an integer in the program and the programmer did not have to worry
about how the hardware did its work -- or even know what the hardware
was.

SQL and other modern programming languages carry this idea further and
try to completely separate logical and physical implementations. The
idea is that SQL is based on sets (which have no ordering) and a
standard that defines its logical behavior. The behavior has nothing
to do with whether a product uses B-Tree indexes, bit vectors or
hashing; two complement or base ten arithmetic; whether the host
program calling the SQL is C or Cobol; etc.

The IDENTITY column in SQL Server is an attempt to return to those
thrilling days of yeasteryear, and the the conceptual junk left over
from the days when people did not know much about relational
databases. What we knew was sequential file systems -- punch cards and
magnetic tapes. Even the disk file systems mimicked these systems,
adding only simple indexes.

Sequence was a basic way of looking at data. People thought in terms
of them at a primitive level. A sequence of bits make a byte, a
sequence of bytes make a field, a sequence of fields make a record and
sequence of records make a file. Very low level, very close to the
machinery.

Then along comes the relational model. It is based on sets; a set is a
completed whole, without any ordering to it. No sequences! Very
abstract! Programmers did not know how to cope, so the vendors exposed
the physical implementation and called these things "features" and
locked their products to particular architectures. I can go into
details on that problem, but let me say that when we went to the bar
after ANSI X3H2 meetings, the vendors griped about what they had to do
to these extensions to preserve them in the next platform, how they
could not scale up to data warehouse size databases, etc.

The IDENTITY column is one of these mistakes.

1) It is not part of the SQL-92 Standard and it is highly proprietary
to the Sybase family. It is not portable -- not quite the same thing
as proprietary, since you can often translate one SQL dialect into
another with a simple replacement (i.e. the % operator becomes the MOD
() function). So your code will not move over to a new database.

2) IDENTITY looks like a datatype, but it is not. Create a table with
one column in it and make it an IDENTITY column. Insert a number into
the table and see what happens. Try to set it to NULL. If you cannot
insert, update and delete all the columns, then this is not a table!

3) IDENTITY looks like a constraint, but it is not. Try to create a
table with two IDENTITY columns and it fails. If you cannot add it to
a column, then it is not a constraint. It is possible to write a a set
of constraints that prohibit data from ever being put in the table
(their predicate is always FALSE). It is possible to write a a set of
constraints that allow anything in the table (their predicate is always
TRUE). But no constraint can prohibit the creation of the table
itself -- that is a meta-constraint.

4) It is not relational. Consider this statement on a table, Foo,
which has an identity column. Assume the query returns more than one
row.

INSERT INTO Foo (x)
SELECT a FROM Bar;

You will get a result like this:

IDENTITY X
============
1 'a'
2 'b'
3 'c'

but if the query changed an index or was put on the physical disk data
page differently, you might have gotten:

IDENTITY X
============
1 'b'
2 'c'
3 'a'

Explain why one result is the logically correct choice for an
identifier and all other choices are not, without any reference to the
physical implementation. You cannot.

Instead of treating the query as a set, you are doing 1950's sequential
processing using the underlying sequential file system the Sybase
family started with.

5) If you have designed your tables correctly, they will have a
meaningful primary key derived from the nature of the entity they
model. The IDENTITY column should be a redundant key. The reason
IDENTITY columns are popular as keys is that they are easy to declare.
This is also the same reason that people build non-normalized databases
and put pennies in fuse boxes -- easy is not right.

6) It is a bitch to do calculations on IDENTITY column values. Well,
it was hard to do direct math on the sequential position of a record in
a 1950's punch card system and that it what the IDENTITY is mimicking.

7) There is no check digit in an IDENTITY columns value, so you have no
way of verifying it if you use it as a key.

8) If you use IDENTITY as a key, the values tend to cluster on physical
data pages because they are sequential. The result is that if the most
recent rows are the most likely to be accessed, there will be locking
contention for control of those physical data pages. What you really
wanted in a key is some spread of the rows over physical storage to
avoid having every user trying to get to the same page at the same
time.

9) The actual implementation of the IDENTITY column has been
problematic since Version 7.0. You can look up threads in the news
groups to get assorted tales of woe.

There are other ways of getting a unique identifier for a table. The
most portable method for getting a new identifier number which is not
in the set is something like this:

INSERT INTO Foobar (keycol, a, b, c...)
VALUES(COALESCE((SELECT MAX(keycol) FROM Foobar) +1, 0),
aa, bb, cc, ...);

The scalar subquery expression returns the current high value for the
key column, and then increments it. If there is no maximum value (i.e.
this is the first row to be inserted), then it returns zero.

Using this basic idea, you can replace the increment with a different
constant or a random number generator. You can also add code to create
a check digit.

Another method is to hash the columns that make up a compound key so
that you have single short column that can be reconstructed if you need
to verify it.

--CELKO--
Joe Celko, SQL Guru & DBA at Trilogy
When posting, inclusion of SQL (CREATE TABLE ..., INSERT ..., etc)
which can be cut and pasted into Query Analyzer is appreciated.
---
Trilogy, FORTUNE, and Goldman Sachs are hosting the E-Business event of
the year. Find out more by visiting www.battleroyale2001.com


Sent via Deja.com
http://www.deja.com/

Brandon Lilly

unread,
Jan 31, 2001, 4:22:26 PM1/31/01
to
So I guess the score is currently tied at:

IDENTITY: 1
UNIQUEIDENTIFIER: 1
Joe Celko: 1

However, since non-sql purists (anyone who believes in either IDENTITY or
UNIQUEIDENTIFIER) are part of the force of darkness, we have:

Forces of Darkness: 2
Joe Celko: 1

*grin*

Brandon Lilly
--
Please remove "nospam_" from email address to reply.


BP Margolin

unread,
Jan 31, 2001, 4:31:28 PM1/31/01
to
Joe,

> My opponents, who I
> am sure will drawn here shortly, are in league with the Forces of
> Darkness <g>.

Interesting from a man who always dresses in black suits, and even claims to
sleep in black pajamas :-)

Sounds to me like Satan trying to convince us that he a'int the Devil :-)

BPM

a29...@my-deja.com

unread,
Jan 31, 2001, 4:27:54 PM1/31/01
to
Numeric primary keys have the advantage of being possible to store in
tags in all kind of controls, so not uniqueidentidiers since they are
alphanumeric.
If you choose numeric keys you have the "religious choice" of using an
identity construct or the SELECT MAX + 1 -way. See other threads.
If you choose the identity way you have to choose datatype. Most people
seems to choose integer, however they have limitations +/- ~2000000.
Consider using the construct COLUMN INTEGER IDENTITY(–2147483647 , 1)
if you expect many rows or use DECIMAL (18,0).
The unique identifier is SUPPOSED to be unique universal. Tales of the
opposite has flown around.

/a

In article <#A77Ss7iAHA.2076@tkmsftngp03>,

BP Margolin

unread,
Jan 31, 2001, 5:00:51 PM1/31/01
to
> The unique identifier is SUPPOSED to be unique universal. Tales of the
> opposite has flown around.

Not a big user of GUIDs, and consequently not particularly knowledgeable
about them ... but the understanding I have is that Microsoft guarantees the
GUID to be unique only if the box has a network card in it. Boxes without
netword cards, as I understand it, might generate duplicate GUIDs.

Again, just what I have heard ... so I could be completely wrong.

----------------------------------------------------------------
BP Margolin
Please reply only to the newsgroups.
When posting, inclusion of SQL (CREATE TABLE ..., INSERT ..., etc.) which

lindawie

unread,
Jan 31, 2001, 5:27:23 PM1/31/01
to
BP,

The mac address is embedded in the guid, so you are right, no network card -
no real uniqueness. We are starting to use guids a lot (my boss likes them
:-( ) so we have to make sure that they are only assigned on the server and
not on any of our portable devices.

Linda


"BP Margolin" <bpm...@attglobal.net> wrote in message
news:ewpNHD9iAHA.1820@tkmsftngp03...

Fred Chateau

unread,
Feb 1, 2001, 12:59:43 AM2/1/01
to
"Joe Celko" <71062...@compuserve.com> wrote in message
news:959qm9$ui8$1...@nnrp1.deja.com...

> Real SQL programmers use real keys and do not try to imitate 1950's
> magnetic tape or punch card systems in a relational model. In the
> early days of programming languages, we exposed a lot of the physical
> and hardware implementation to the programmer. For example, COBOL and
> FORTRAN depend on physically contiguous storage of data, which made a
> ROWID (i.e. physical location reference) possible.

Thank you for your most informative discussion.

Isn't there a performance advantage to having records arranged, if not
sequentially, at least semi-sequentially, in a table?

--
Regards,

Fred Chateau
http://members.home.net/fchateau/

lindawie

unread,
Feb 1, 2001, 2:29:38 AM2/1/01
to
Fred,

I have a table in production that is growing at the rate of about 1 million
rows a day, although that can vary anywhere from 500,000 to 1,5 million rows
per day (our business is somewhat seasonal). Having all rows physically
arranged in exactly the sequential order that we need to access them gives
us a **huge** performance advantage. We can process a whole day's worth of
new data in a few minutes on a midrange server, with a sustained throughput
of more than 1,000 rows per second. And, yes, this in only possible because
we use identity columns. I have run tests to try out the alternate methods
posted here and elsewhere. The best performance I ever achieved was a
sustained throughput of about 10 rows per second. Interestingly, any
solutions involving aggregate functions (select count(*) or select max() )
are the slowest, about 1 row per second. So you can do the math to figure
out how many days it would take to process a single day's worth of data.

Two things that I really like in life are fast cars and fast databases, and
I am lucky enough to have both. :-)

Linda

"Fred Chateau" <fcha...@home.com> wrote in message
news:OKN#uQBjAHA.1648@tkmsftngp03...

Tibor Karaszi

unread,
Feb 1, 2001, 2:26:56 AM2/1/01
to
> Isn't there a performance advantage to having records arranged, if not
> sequentially, at least semi-sequentially, in a table?

There certainly can be. But that arrangement is not exposed at the logical (SQL)
level.
(Assuming that you refer to, for instance, a clustered index...)

--
Tibor Karaszi, SQL Server MVP
FAQ from Neil at: http://www.sqlserverfaq.com
Please reply to the newsgroup only, not by email.


"Fred Chateau" <fcha...@home.com> wrote in message
news:OKN#uQBjAHA.1648@tkmsftngp03...

Fred Chateau

unread,
Feb 1, 2001, 3:59:49 AM2/1/01
to
"lindawie" wrote ...

> Two things that I really like in life are fast cars and fast databases,
and
> I am lucky enough to have both. :-)

Makes common sense . . .

There's got to be a performance price for all that relational processing
convenience, but I didn't think it would be that high.

I wonder if there's a correlation between the programmers here who advocate
GUID's and the size of their databases.

Tibor Karaszi

unread,
Feb 1, 2001, 7:01:27 AM2/1/01
to
> The mac address is embedded in the guid, so depending on your point of view,
> this is an advantage or a drawback. Theoretically an instance of data could
> be traced back to its machine of origin. It could be argued that this as
> nice control mechanism or a privacy issue.

It might be worth noticing that W2K scrambles this so you don't "see" that a set of
guid's come from the same machine.

(Though I fully agree with your reasoning, Linda....)


--
Tibor Karaszi, SQL Server MVP
FAQ from Neil at: http://www.sqlserverfaq.com
Please reply to the newsgroup only, not by email.


"lindawie" <lind...@my-deja.com> wrote in message
news:O7VDQ17iAHA.1740@tkmsftngp05...


> Bob,
>
> I always use a long integer for identity columns.

<snip>


lindawie

unread,
Feb 1, 2001, 9:53:08 AM2/1/01
to
Fred,

I guess I was a bit ambiguous there. When I said "alternate methods posted
here and elsewhere" I meant this and other newsgroups, books, magazines. I
never did any of these tests using guids for keys. However, my boss has
susbatantial experience with guids, he loves the things, and he says they
scale just fine. The solutions I tried were some of the proposed
alternatives to using the identity property -- sequence table, select
max(MyPrimaryKeyID) + 1..., hashed pregenerated sequence numbers, that sort
of thing.

Anyway, it just confirmed once again what I have known all along, that SQL
Server can do a better job of taking care of its own business than I can, so
I should just relax and let it do its thing.

Linda

"Fred Chateau" <fcha...@home.com> wrote in message

news:uftHY1CjAHA.1740@tkmsftngp05...

ferret...@my-deja.com

unread,
Feb 1, 2001, 2:17:07 PM2/1/01
to
I have to throw my vote in for GUIDs as IDs. While long winded, Celko
has a very good point that there is absolutely no reason for the
primary key to be sequential. Almost all operations should index
another, more logically useful value for queries, such as an insert or
update date, or something that MEANS something by its sequential
nature, etc. The purpose of a primary key is single-fold, to uniquely
identify the row. IDENTITY does not do this very well, but a GUID does
this excellently.

As to performance issues, the size of the key itself should be the only
issue, so this is something you will have to explore on a case-by-case
basis. Good indexing should nullify most of the performance issues in
joins, however, so the only thing left performance-wise, is the simple
impact of moving a bit more data per row and the size of the whole
database being greater.

As to the "possibility" of a GUID not being unique, first off what
machine doesn't have a network card? How are you going to get the data
off that machine, with floppies? :) Ok, ok, so recordable media is
finally seeing some improvement. Second, with the MAC address and a
date-time stamp in the GUID, your system would have to be capable of an
absolutely ungodly number of inserts within a single second to even
come close to producing a duplicate key, something beyond the
capabilities of our current technology, and most-likely, for a good
time to come.

I vote for GUIDS. I'm about to implement them on the biggest database
I've designed so far (very high growth rate), so I'll let you know
about any performance issues in about six months :)


In article <#A77Ss7iAHA.2076@tkmsftngp03>,
"Bob" <bil...@holt.k12.mi.us> wrote:

Kevin Connell

unread,
Feb 1, 2001, 3:09:31 PM2/1/01
to
And what you're saying, in a long winded way, is: DON'T USE FACTS IN KEYS.
Sequences could be considered facts. Same goes for @@DBTS

Also, as for the uniqueness of GUIDs, there's a dependancy on MAC addresses
being unique..... Keep this in mind: IPV6 includes the MAC address as part
of the ip address. but only part of it. Hmm.

<ferret...@my-deja.com> wrote in message
news:95ccn7$5od$1...@nnrp1.deja.com...

timothy...@my-deja.com

unread,
Feb 1, 2001, 3:26:29 PM2/1/01
to

> The difference between them is that the identity is incremental, so,
in a
> trading system for instance inserted rows would be grouped together
in the
> table giving rise to less IO (less page reads) to query recent date -

But that can be a detriment for OLTP.
You have a tradeoff of select vs. insert/update, for the page, and for
resource contention. So it depends on how the system is used: more
reading or more writing? ... and your isolation level.

Joris Laperre

unread,
Feb 2, 2001, 1:33:51 AM2/2/01
to
In fact, we have found the opposite to be true... We saw an enormous
performance degradation
with the move to Win2k/SQL2k. The reason was that the NEWID() returned a
completely random
number (under NT 4.0 it was kind-of-sequential), so practically every insert
dirtied a new page.
Our OLTP system (65 GB, growing at 1GB a week) was checkpointing like there
was no tomorrow
and almost every query timed out during each checkpoint. We worked around it
by creating our
guids in our middle-tier code (they're Win2k too, but there's an api call
that lets you create "old-style"
guids).

So yes, guids work well as primary keys for big systems as long as you don't
use NEWID() to generate
them (at least not for big tables).

Joris Laperre

<timothy...@my-deja.com> wrote in message
news:95cgp9$9qk$1...@nnrp1.deja.com...

BP Margolin

unread,
Feb 2, 2001, 10:12:50 AM2/2/01
to
Joris,

You apparently had a clustered index on the NEWID( ) column ...

Offhand, I can't think of any good reason for clustering on a random number.

----------------------------------------------------------------
BP Margolin
Please reply only to the newsgroups.
When posting, inclusion of SQL (CREATE TABLE ..., INSERT ..., etc.) which
can be cut and pasted into Query Analyzer is appreciated.

"Joris Laperre" <joris....@hospital2000.com> wrote in message
news:#MpNvIOjAHA.2128@tkmsftngp03...

Joris Laperre

unread,
Feb 3, 2001, 12:29:14 AM2/3/01
to
Hi,

Correct, we have a clustered index on that newid(); it is also the primary
key.
I am aware of all the issues involved in choosing the clustered key and
understand that the primary
key is not necessarily the best choice for a clustered index. However, I
found that, if you have a lot
of different queries joining on table X, the primary key of table X is the
best choice for the clustered
index (otherwise you get an index seek followed by a clustered index seek,
as opposed to just a
clustered index seek).

Cheers,
Joris Laperre

"BP Margolin" <bpm...@attglobal.net> wrote in message

news:OQ1ZWoSjAHA.2160@tkmsftngp03...

BP Margolin

unread,
Feb 3, 2001, 1:41:17 AM2/3/01
to
Joris,

Have you actually tried changing it to a non-clustered index to see how it
might affect performance ... you should certainly keep it as a primary key,
just un-cluster it.

My standard approach when dealing with PK / FK relationships is to cluster
the "natural" keys of the many side of a 1-to-many relationship ... not
infrequently, one needs to pull in all the children of a parent, and it's
better to have all the children clustered.

Hope this makes sense ... I don't know that I'm explaining it too well :-(

----------------------------------------------------------------
BP Margolin
Please reply only to the newsgroups.
When posting, inclusion of SQL (CREATE TABLE ..., INSERT ..., etc.) which
can be cut and pasted into Query Analyzer is appreciated.

"Joris Laperre" <joris....@hospital2000.com> wrote in message

news:eYukXJajAHA.492@tkmsftngp03...

Joris Laperre

unread,
Feb 3, 2001, 4:37:14 AM2/3/01
to
Hi again,

I had tried it before but threw away the results, so I did a new test.
One of our frequently executed queries (200 times per hour) is: give me the
list
of patients (table person) currently on visit (table patient_visit, with a
foreign key
into the person table) in the hospital. We have easily over 50 queries with
a
similar pattern. I've pasted the IO stats in:
1) With our current design: the guid primary key as clustered index
(clustered index seek):
Table 'person'. Scan count 670, logical reads 2135, physical reads 0,
read-ahead reads 0.
Table 'patient_visit'. Scan count 1, logical reads 9, physical reads 0,
read-ahead reads 0.
2) With the guid primary key nonclustered and another clustered index (index
seek followed
by bookmark lookup):
Table 'person'. Scan count 670, logical reads 4220, physical reads 0,
read-ahead reads 0.
Table 'patient_visit'. Scan count 1, logical reads 9, physical reads 0,
read-ahead reads 0.

The logical reads have gone up from 2135 to 4220. The execution time also
went up from 38 to 65 msec.

Joris Laperre

"BP Margolin" <bpm...@attglobal.net> wrote in message

news:ej81KvajAHA.2164@tkmsftngp05...

BP Margolin

unread,
Feb 3, 2001, 11:57:11 AM2/3/01
to
Joris,

Thanks for the stats ... what concerns me is the very high numbers on the
table person ... that seems to be where the significant performance hit is
being taken ... might you need some index on that table to improve
performance?

----------------------------------------------------------------
BP Margolin
Please reply only to the newsgroups.
When posting, inclusion of SQL (CREATE TABLE ..., INSERT ..., etc.) which
can be cut and pasted into Query Analyzer is appreciated.

"Joris Laperre" <joris....@hospital2000.com> wrote in message

news:#Fhw8TcjAHA.1104@tkmsftngp02...

Erland Sommarskog

unread,
Feb 3, 2001, 5:31:47 PM2/3/01
to
BP Margolin (bpm...@attglobal.net) writes:
>You apparently had a clustered index on the NEWID( ) column ...
>
>Offhand, I can't think of any good reason for clustering on a random number.

I seem to recall that Henry Lau of Microsoft suggests this stratgey
in a white-paper on SQL7 performance, but I'm too lazy to verify
that now.

Actually, we are about to try this on Monday, although we won't be
using NEWID(), since we're SQL6.5. Rather we will use a key composed
of the current millisecones, minutes, hours and the spid. This isn't
really a primary key, but a process key in a sort of temporary
table. Previously we just had a decrementing number starting on -1
each morning. But this very critical procedure is run many times
a day, and simutaneous runs are by no means uncommon. Two processes
may well be running at the same time, are likely to fight about the
same page, yeah, you guessed it, we are trying to decrease the number
of deadlocks.

(Why a decrementing number? Actually the default of this SP is to
use @@spid, but the most common calls first reserve a key, and
pass this key to the procedures.)

--
Erland Sommarskog, Stockholm, som...@algonet.se

Joris Laperre

unread,
Feb 4, 2001, 1:49:29 AM2/4/01
to
Hi,

All the correct indexes are there. These numbers make sense: the query
returns
670 visits, for each of these (it's a loop join) it must look up the
patient's name
by its person_id which is a guid, i.e. random. There are 590000 records in
that table,
taking up 30000 data pages. 670 reads for the leaf level pages (let's assume
they're all
on different pages) of the clustered index and 1465 reads in the index tree
to get
to the leaf pages. High, but not abnormal.

Thanks for taking your time on this one.

Joris Laperre

"BP Margolin" <bpm...@attglobal.net> wrote in message

news:#iNzVHgjAHA.432@tkmsftngp02...

nagaraj...@gmail.com

unread,
Mar 16, 2005, 6:34:11 AM3/16/05
to
How did this go ? is it performing fine now ??
Im now designing a huge db. so i need to know before doing it..

Thanks
SN

0 new messages