Re: [PHP-DB] VFP 6 via ODBC and data integrity questions
OK, I know what I have to do. I thank you for all of your help and I will use your idea of a select, then update and then capture all errors to try again. Hopefully, this will minimize problems in the future. Thanks, Brian PJC Services At 06:45 PM 2/3/2003, you wrote: 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. 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? 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. 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 --- 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
Re: [PHP-DB] VFP 6 via ODBC and data integrity questions
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. 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? 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. 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
Re: [PHP-DB] VFP 6 via ODBC and data integrity questions
Currently they are using a VFP client app, the actual program is not installed. 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. 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
Re: [PHP-DB] VFP 6 via ODBC and data integrity questions
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
Re: [PHP-DB] VFP 6 via ODBC and data integrity questions
> 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? Just insert the name and look for an error coming back to you. There's some way to get the error reported by the database with ODBC, isn't there? Parse the error returned for something like "duplicate key" and then you'll know the username wasn't unique and they need to find another. ---John Holmes... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] VFP 6 via ODBC and data integrity questions
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
