Same here, but we go a little step further and the PKs are globally unique, so
in essence the client app can do everything without ever hitting the server.

The performance hit is negligible when compared to the flexibility gained.

Raf


Woody (TMW) wrote:

>>Fred,
>>
>>
>>>>We *never* allow an application (user) to supply the PK value.
>>
>>I do it all the time. :-)
>>
>>It's quite easy to define a PK value in the client, post the data, and
>>'refresh' the values from the server using the primary key to identify the
>>row. A trigger will guarantee that a PK get's the value if the client
>>doesn't provide it.
>>
>>We don't care about any 'jumps' in values, we use just one generator to
>
> all
>
>>tables. I have lot's of this 'jumps', but since the generator works
>
> outside
>
>>the transaction, I just get a unique identifier of the row. I really don't
>>care about a generator value - it could be positive, negative, as long as
>
> it
>
>>really is unique. And it always is.
>>
>
>
> I get/assign the generator values from the client as well. The main reason
> is that you have immediate access to the value for use in creating child
> records, etc. If the value is assigned at the server, you have to re-query
> in order to obtain the value.
>
> Woody (TMW)
> Freeware Page: http://users.eonet.net/woodytmw
>
> All computers wait at the same speed.
>
>
>
> To unsubscribe from this group, send an email to:
> firebird-support-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

--
Rafael Szuminski
Email:raf@...
Phone:(949)939 - 2458
www.BDCSoftware.com