At 06:25 PM 2/3/2003 -0500, Brian Evans wrote:
Currently they are using a VFP client app, the actual program is not installed.No, I wouldn't think so, it's a native VFP function. I'm wondering if you could clone something, by using rand(), seeded with the unix time and client's IP number. Don't take me too seriously, I'm just musing here.
I just discovered that the suggestion you offered (about a key table) is being used by this client.
Would the sys() function work through ODBC w/o the full VFP install?
How do I lock the database through PHP and ODBC for a moment?? I cannot find any information on this.Probably you can't. but I'm wondering if you could SELECT the keyvalue you need, then immediately execute an update, setting keyvalue to keyvalue + 1, assuming it's numeric. What would that be like, something along the lines of
update keys ( keyvalue), ( str( val(keyvalue) + ) ) where tablename = 'var_tablename'
The val expression converts the existing keyvalue to a numeric which allows a numeric one to be added, returning that expression as a string. (Unless I have their functionality reversed, but I hope you get the idea.)
With his you don't have to worry about the lock and the value will be appropriately updated. Again the question is what kind of functions can you use through ODBC; I've not ever had to work with it.
HTH - Miles Thompson
Thanks for your help. Brian PJC Services At 03:13 PM 2/3/2003, you wrote: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
--- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003
-- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
