Thanks!I think that the only way to accomplish this is to use the NEWID() function before your INSERT statement to explicitly assign the value.
David Penton has a stored proceudre which explains this technique:A example of returning a guid as an "Identity" in ADO
Terri|||Why would you like this?
Why do you not create the GUID on the client side?
GUID's are defiend to be unique wherever you create them. There is - contrary to identity fields - no need to have the server define them.
This is the beauty of them - I know them when the object they mark (if they are the PK) is created, not once it is inserted into the database.|||I would like this because I know, like, and respect David Penton.
Yes, having the client create the GUID would be another way to go. I don't see a real advantage of creating the GUID on the client side, however.
To me, a row identifier is something that SQL needs and cares about, and the client couldn't care less about. So why would the client have the job of creating it?
Maybe you can explain further.
Terri|||::Why would you like this?
::Why do you not create the GUID on the client side?
This is what I ended up doing.|||::To me, a row identifier is something that SQL needs and cares about, and the client couldn't
::care less about.
In this casse, why does teh client need to know at all?
If the ROWGUID is simply used as replication identifier, for example, the client can be "ignorant" and just ignore it.
Obviously, for some reason, this is not the case - the client needs to know.
And then, i f it needs to know, and inserts the row anyway, it can also determine it.
::So why would the client have the job of creating it?
Because the client inserts the row and obviously does something with the id, otherwise it would not requrey for it.
I assume it is some sort of primary key, too.
And here is is much easier to work with a guid the moment you create the row, instead of inserting it later.
No comments:
Post a Comment