There's an alternate route, but I've used it only over a network, not across the internet.

Create a keys table which has two fields - tablename and keyvalue.

Create a Get_VFP_Key function with one parameter, the tablename, which returns the keyvalue for that table name.

Get_VFP_Key gets a lock on the row containing the tablename, grabs the value, increments it according to whatever scheme you are using, writes the new value and releases the lock. A friend of mine used the ascii table and generated base 256 keys, rather an exceptional fellow.

The problem I see here is latency and a locking problem.

Alternately, if the machine you are hitting is running VFP, why not use its native sys(2015) (or 2017 - can't remember just now) to generate a random key.

HTH - Miles Thompson

BTW Character-based primary keys are quite common in the VFP world because FoxPro did not cleanly handle a mix of numeric and character fields in the WHERE portion of a SELECT. It wanted all character values, so don't be too hard on the morons.

How are they handling the generation of primary keys?



At 09:43 AM 2/3/2003 -0500, Brian Evans wrote:
Good day all,

I have just began work on a project to let users subscribe to a service and place orders into a database that is VFP 6 based.

Using PHP4, I am able to interface with their program (that also uses ODBC locally) in all aspects (INSERT, UPDATE, DELETE, and SELECT).

My worries come when inserting a new user/order from the web.

The morons who designed the database made the Primary Key as character and NULLable (once only of course), but I have to deal with that.

My question is this...

How can I know the new user I INSERT will be unique? (the field is character, but counts like a number field) This especially holds true since I have to deal with local users possibly adding at the exact same moment as PHP (ie. a racing issue).

Can anyone tell me how to avoid problems?

Would odbc_prepare() reserve a new key for me?

Thanks.

Brian
PJC Services

P.S. Kudos to all of the developers. This is a great job you guys are doing.



--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to