Re: [PHP-DB] Slow Query
How many agents do you have? If the number of agents is small then you could set up a temp table which has a link to the agent, the client, and a calculation of the distance between the two. Then do your search on this temp table. Once you have the answer you want delete the records for this client. (that should allow for more than one client entering data at the same time, although you may want to properly think that scenario through) graeme. Wendell Frohwein wrote: First of all I would like to thank anyone who lends a hand in this matter. Here is what im working with. Redhat 9, PHP 5.0.2, Apache/2.0.50, MySQL 4.1.8-standard Binary Installation for pc-linux-i686, OpenSSL 0.9.7d, gcc version 3.2.2. PHP compiled with mysql, and mysqli capability. This is how the script works: The client submits a property for an appraisal. Based on the appraisal type and property zip code, It searches the database for agents / appraisers with the zip code in question (property zip code) in there coverage area (zip codes they are willing to do appraisal work for). So when it finds a match, It adds that order to there potential order list. It then waits for the to accept or decline the order. If accepted the order becomes there's and alerts all the other agents / appraisers that this order has already been accepted. The do the work, send it back job is done. This works fine right now rather it be a single order placed by a client, or a spreadsheet imported to the system with 2000 orders or more. So now you're saying if it works, why are you here asking for help? Well instead of searching agents with the exact zip code match, I would like to search a radius of zip codes. The first search would be a 2 mile radius, the next search (incase the first did not return any result) would be 5 mile radius. I purchased some software (php / mysql sql files) that contains every zipcode in the united states along with a longitude and latitude for each zip code. So the zip code script provided with this software allows you to 1) enter a zip code and miles in radius, it will then spit out all the zip codes in that radius into an array. 2) you can give it 2 zip codes and it will tell you the distance in miles between the 2 (give or take). So I rewrote my script to do the follow: The client submits a property for an appraisal. Based on the appraisal type and property zip code, It does a radius search of 2 miles from the property zip. If no matches are found, it does a 5 mile radius search. For every zip code returned by each radius search, It searches the database for agents / appraisers with the zip code in question (zip codes from radius search) in there coverage. This is the most stressful part I am assuming. This works fine for 1 - 10 orders. But when I import 30 or more, the script pretty much hangs as well as mysql. I have to kill mysql with signal 9, start mysql it up again. Then all is back to normal. I would paste the code in here but it is really long and complicated. I was hoping on the based on the operation of the script, someone would suggest a better and faster way to search zip code radius, while matching the results to agents within the system. If I am asking for way to much time from someone, I apologize. If someone is really interested in helping me sort this out, I could send you code samples to see the process. -Wendell Frohwein -- Experience is a good teacher, but she sends in terrific bills. Minna Antrim -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] Question regarding how-to stop the form inputting empty data at end of the form that is empty due to a carriage return
Hi Mike, I would suggest that you look for [A-Z],[a-z] and [0-9] characters and build up your string for Media ID instead of replacing \r and \n. I have gone through the same situation for bar code scanning. Regards, Manjiri __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DB] Slow Query
Thank you Graeme. But unfortunately, there are a 700 + agents. This number keeps growing every day as well. I had a vision of another idea. I don't know how much time it will save. In the table that stores all the agents zipcodes that they cover, I added longitude and latitude to the table. So when my zip code radius function kicks in, it will find agents with there respective zip code. Before it would take the property zip, query the zipcodes table with over 42,000 zip codes, then put those in an array, then search for agents from there. The way I see it, I killed one step in the process. But at the time of me writing this letter I am still trying to get it to work. If I do, I will post up some numbers to see how much faster it is. But I am still looking for a better way to do it. Thanks once again to everyone. -Wendell Frohwein -Original Message- From: graeme [mailto:[EMAIL PROTECTED] Sent: Thursday, January 13, 2005 12:02 AM To: Wendell Frohwein Cc: php-db@lists.php.net Subject: Re: [PHP-DB] Slow Query How many agents do you have? If the number of agents is small then you could set up a temp table which has a link to the agent, the client, and a calculation of the distance between the two. Then do your search on this temp table. Once you have the answer you want delete the records for this client. (that should allow for more than one client entering data at the same time, although you may want to properly think that scenario through) graeme. Wendell Frohwein wrote: First of all I would like to thank anyone who lends a hand in this matter. Here is what im working with. Redhat 9, PHP 5.0.2, Apache/2.0.50, MySQL 4.1.8-standard Binary Installation for pc-linux-i686, OpenSSL 0.9.7d, gcc version 3.2.2. PHP compiled with mysql, and mysqli capability. This is how the script works: The client submits a property for an appraisal. Based on the appraisal type and property zip code, It searches the database for agents / appraisers with the zip code in question (property zip code) in there coverage area (zip codes they are willing to do appraisal work for). So when it finds a match, It adds that order to there potential order list. It then waits for the to accept or decline the order. If accepted the order becomes there's and alerts all the other agents / appraisers that this order has already been accepted. The do the work, send it back job is done. This works fine right now rather it be a single order placed by a client, or a spreadsheet imported to the system with 2000 orders or more. So now you're saying if it works, why are you here asking for help? Well instead of searching agents with the exact zip code match, I would like to search a radius of zip codes. The first search would be a 2 mile radius, the next search (incase the first did not return any result) would be 5 mile radius. I purchased some software (php / mysql sql files) that contains every zipcode in the united states along with a longitude and latitude for each zip code. So the zip code script provided with this software allows you to 1) enter a zip code and miles in radius, it will then spit out all the zip codes in that radius into an array. 2) you can give it 2 zip codes and it will tell you the distance in miles between the 2 (give or take). So I rewrote my script to do the follow: The client submits a property for an appraisal. Based on the appraisal type and property zip code, It does a radius search of 2 miles from the property zip. If no matches are found, it does a 5 mile radius search. For every zip code returned by each radius search, It searches the database for agents / appraisers with the zip code in question (zip codes from radius search) in there coverage. This is the most stressful part I am assuming. This works fine for 1 - 10 orders. But when I import 30 or more, the script pretty much hangs as well as mysql. I have to kill mysql with signal 9, start mysql it up again. Then all is back to normal. I would paste the code in here but it is really long and complicated. I was hoping on the based on the operation of the script, someone would suggest a better and faster way to search zip code radius, while matching the results to agents within the system. If I am asking for way to much time from someone, I apologize. If someone is really interested in helping me sort this out, I could send you code samples to see the process. -Wendell Frohwein -- Experience is a good teacher, but she sends in terrific bills. Minna Antrim -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DB] Slow Query
Here is the structure of the zipcodes table CREATE TABLE `zipcodes` ( `zipcode` mediumint(5) unsigned zerofill NOT NULL default '0', `lon` varchar(8) NOT NULL default '', `lat` varchar(8) NOT NULL default '', PRIMARY KEY (`zipcode`), KEY `lon` (`lon`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; And here is an example of one of the inserts INSERT INTO `zipcodes` VALUES (00501, '73.0456', '40.8153'); I am retrieving this data from phpmyadmin 2.6.0-rc2 Thanks again. -Wendell Frohwein -Original Message- From: Bastien Koert [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 12, 2005 6:12 PM To: [EMAIL PROTECTED]; php-db@lists.php.net Subject: RE: [PHP-DB] Slow Query are there indeces on the tables columns? Also does your query use the IN (zip1, zip2, zipN) format or or do you query for each zip individually? The second is absolute killer on the db bastien From: Wendell Frohwein [EMAIL PROTECTED] To: php-db@lists.php.net Subject: [PHP-DB] Slow Query Date: Wed, 12 Jan 2005 14:48:20 -0800 First of all I would like to thank anyone who lends a hand in this matter. Here is what im working with. Redhat 9, PHP 5.0.2, Apache/2.0.50, MySQL 4.1.8-standard Binary Installation for pc-linux-i686, OpenSSL 0.9.7d, gcc version 3.2.2. PHP compiled with mysql, and mysqli capability. This is how the script works: The client submits a property for an appraisal. Based on the appraisal type and property zip code, It searches the database for agents / appraisers with the zip code in question (property zip code) in there coverage area (zip codes they are willing to do appraisal work for). So when it finds a match, It adds that order to there potential order list. It then waits for the to accept or decline the order. If accepted the order becomes there's and alerts all the other agents / appraisers that this order has already been accepted. The do the work, send it back job is done. This works fine right now rather it be a single order placed by a client, or a spreadsheet imported to the system with 2000 orders or more. So now you're saying if it works, why are you here asking for help? Well instead of searching agents with the exact zip code match, I would like to search a radius of zip codes. The first search would be a 2 mile radius, the next search (incase the first did not return any result) would be 5 mile radius. I purchased some software (php / mysql sql files) that contains every zipcode in the united states along with a longitude and latitude for each zip code. So the zip code script provided with this software allows you to 1) enter a zip code and miles in radius, it will then spit out all the zip codes in that radius into an array. 2) you can give it 2 zip codes and it will tell you the distance in miles between the 2 (give or take). So I rewrote my script to do the follow: The client submits a property for an appraisal. Based on the appraisal type and property zip code, It does a radius search of 2 miles from the property zip. If no matches are found, it does a 5 mile radius search. For every zip code returned by each radius search, It searches the database for agents / appraisers with the zip code in question (zip codes from radius search) in there coverage. This is the most stressful part I am assuming. This works fine for 1 - 10 orders. But when I import 30 or more, the script pretty much hangs as well as mysql. I have to kill mysql with signal 9, start mysql it up again. Then all is back to normal. I would paste the code in here but it is really long and complicated. I was hoping on the based on the operation of the script, someone would suggest a better and faster way to search zip code radius, while matching the results to agents within the system. If I am asking for way to much time from someone, I apologize. If someone is really interested in helping me sort this out, I could send you code samples to see the process. -Wendell Frohwein -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] reorder records with phpMyadmin ?
well...thanks for all of the info for myself, I have to order a lot of playlists of video movies and was looking for a faster way to do this...seems that drag and drop would be ideal ? anyone know of a better way maybe some one knows of a mysql application that allready has this feature ? currently, I am doing all the phpmyadmin stuff myself...users are getting access to mysql by a wired Quicktime interface...kind of like Flash PlayerThey can insert records and query thru thiswhich is heavily filtered when it hits my php script... I'll take a look at a Director/Runtime Rev solution...sounds like that may be a bit less trouble than a web interface... g -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DB] Slow Query
Hi Wendell, What you've proposed is not a bad solution. There is some initial work to set up the stuff for the existing agents, but if you define a limit to the range that the agent works in, then you can take the result stuff it into a comma delimited string and place that into the agent_zip_codes field...then the realtime time query is a simple IN (zip1, zip2, zipN) statement and should be faster Bastien From: Wendell Frohwein [EMAIL PROTECTED] To: 'graeme' [EMAIL PROTECTED] CC: php-db@lists.php.net Subject: RE: [PHP-DB] Slow Query Date: Thu, 13 Jan 2005 00:30:34 -0800 Thank you Graeme. But unfortunately, there are a 700 + agents. This number keeps growing every day as well. I had a vision of another idea. I don't know how much time it will save. In the table that stores all the agents zipcodes that they cover, I added longitude and latitude to the table. So when my zip code radius function kicks in, it will find agents with there respective zip code. Before it would take the property zip, query the zipcodes table with over 42,000 zip codes, then put those in an array, then search for agents from there. The way I see it, I killed one step in the process. But at the time of me writing this letter I am still trying to get it to work. If I do, I will post up some numbers to see how much faster it is. But I am still looking for a better way to do it. Thanks once again to everyone. -Wendell Frohwein -Original Message- From: graeme [mailto:[EMAIL PROTECTED] Sent: Thursday, January 13, 2005 12:02 AM To: Wendell Frohwein Cc: php-db@lists.php.net Subject: Re: [PHP-DB] Slow Query How many agents do you have? If the number of agents is small then you could set up a temp table which has a link to the agent, the client, and a calculation of the distance between the two. Then do your search on this temp table. Once you have the answer you want delete the records for this client. (that should allow for more than one client entering data at the same time, although you may want to properly think that scenario through) graeme. Wendell Frohwein wrote: First of all I would like to thank anyone who lends a hand in this matter. Here is what im working with. Redhat 9, PHP 5.0.2, Apache/2.0.50, MySQL 4.1.8-standard Binary Installation for pc-linux-i686, OpenSSL 0.9.7d, gcc version 3.2.2. PHP compiled with mysql, and mysqli capability. This is how the script works: The client submits a property for an appraisal. Based on the appraisal type and property zip code, It searches the database for agents / appraisers with the zip code in question (property zip code) in there coverage area (zip codes they are willing to do appraisal work for). So when it finds a match, It adds that order to there potential order list. It then waits for the to accept or decline the order. If accepted the order becomes there's and alerts all the other agents / appraisers that this order has already been accepted. The do the work, send it back job is done. This works fine right now rather it be a single order placed by a client, or a spreadsheet imported to the system with 2000 orders or more. So now you're saying if it works, why are you here asking for help? Well instead of searching agents with the exact zip code match, I would like to search a radius of zip codes. The first search would be a 2 mile radius, the next search (incase the first did not return any result) would be 5 mile radius. I purchased some software (php / mysql sql files) that contains every zipcode in the united states along with a longitude and latitude for each zip code. So the zip code script provided with this software allows you to 1) enter a zip code and miles in radius, it will then spit out all the zip codes in that radius into an array. 2) you can give it 2 zip codes and it will tell you the distance in miles between the 2 (give or take). So I rewrote my script to do the follow: The client submits a property for an appraisal. Based on the appraisal type and property zip code, It does a radius search of 2 miles from the property zip. If no matches are found, it does a 5 mile radius search. For every zip code returned by each radius search, It searches the database for agents / appraisers with the zip code in question (zip codes from radius search) in there coverage. This is the most stressful part I am assuming. This works fine for 1 - 10 orders. But when I import 30 or more, the script pretty much hangs as well as mysql. I have to kill mysql with signal 9, start mysql it up again. Then all is back to normal. I would paste the code in here but it is really long and complicated. I was hoping on the based on the operation of the script, someone would suggest a better and faster way to search zip code radius, while matching the results to agents within the system. If I am asking for way to much time from someone, I apologize. If someone is really interested in helping me sort this out, I could send you code samples to see the process. -Wendell Frohwein
RE: [PHP-DB] Slow Query
Thank You Bastien. My newest Vision that I had about taking out a step in the process has failed. Mainly because of the script that determines the radius. Since I was going to go off of the agents zipcode coverage area (to save a step), and not the zipcode table containing 45,000 + entry's. If an order was placed by a client with lets say the zip code 90606, and there was no agent in the entire system that had this exact zip code in there coverage area, the radius code would error out and return no matches. Even though in the 2-5 mile radius of 90606 there is matching agents. It needs to see that first zip codes (90606) longitude and latitude to even begin the radius function. So now I was bumped again. I rewrote some of my code to be a little more streamlined. So I began testing orders: 50, 100, 200, and 400. The time it takes to assign orders to agents is really had to determine because it is based on how many agents and how many zipcodes in those agents coverage area. With 400 orders within a heavy populated area it takes as much time as 127 seconds to process. If there are fewer zip codes in an area such as mid east / west it takes as little time as 11 seconds to process. When I start the assignment of orders I open up a shell via ssh, monitor the system using the top command. Mysqld spikes between 55% and 99% cpu usage the entire time of the assignment process. Where it says User CPU usage its between 70% and 99% cpu usage. And finally where it says System CPU Usage, it rarely goes over 3% - 5%. The server is not mine, but one I manage for the company. I used dmesg to find out that the server this site is running on is a 700mhz celeron coppermine, 128MB of ram, 10gig western digital drive. So with this in mind, I think my problem behind slow queries is affected in other areas other then the script itself. Thank you all very much for all your help. -Wendell Frohwein -Original Message- From: Bastien Koert [mailto:[EMAIL PROTECTED] Sent: Thursday, January 13, 2005 10:04 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: php-db@lists.php.net Subject: RE: [PHP-DB] Slow Query Hi Wendell, What you've proposed is not a bad solution. There is some initial work to set up the stuff for the existing agents, but if you define a limit to the range that the agent works in, then you can take the result stuff it into a comma delimited string and place that into the agent_zip_codes field...then the realtime time query is a simple IN (zip1, zip2, zipN) statement and should be faster Bastien From: Wendell Frohwein [EMAIL PROTECTED] To: 'graeme' [EMAIL PROTECTED] CC: php-db@lists.php.net Subject: RE: [PHP-DB] Slow Query Date: Thu, 13 Jan 2005 00:30:34 -0800 Thank you Graeme. But unfortunately, there are a 700 + agents. This number keeps growing every day as well. I had a vision of another idea. I don't know how much time it will save. In the table that stores all the agents zipcodes that they cover, I added longitude and latitude to the table. So when my zip code radius function kicks in, it will find agents with there respective zip code. Before it would take the property zip, query the zipcodes table with over 42,000 zip codes, then put those in an array, then search for agents from there. The way I see it, I killed one step in the process. But at the time of me writing this letter I am still trying to get it to work. If I do, I will post up some numbers to see how much faster it is. But I am still looking for a better way to do it. Thanks once again to everyone. -Wendell Frohwein -Original Message- From: graeme [mailto:[EMAIL PROTECTED] Sent: Thursday, January 13, 2005 12:02 AM To: Wendell Frohwein Cc: php-db@lists.php.net Subject: Re: [PHP-DB] Slow Query How many agents do you have? If the number of agents is small then you could set up a temp table which has a link to the agent, the client, and a calculation of the distance between the two. Then do your search on this temp table. Once you have the answer you want delete the records for this client. (that should allow for more than one client entering data at the same time, although you may want to properly think that scenario through) graeme. Wendell Frohwein wrote: First of all I would like to thank anyone who lends a hand in this matter. Here is what im working with. Redhat 9, PHP 5.0.2, Apache/2.0.50, MySQL 4.1.8-standard Binary Installation for pc-linux-i686, OpenSSL 0.9.7d, gcc version 3.2.2. PHP compiled with mysql, and mysqli capability. This is how the script works: The client submits a property for an appraisal. Based on the appraisal type and property zip code, It searches the database for agents / appraisers with the zip code in question (property zip code) in there coverage area (zip codes they are willing to do appraisal work for). So when it finds a match, It adds that order to there potential order list. It then waits for the to accept or decline the order. If accepted the order
RE: [PHP-DB] Slow Query
me thinks its time for a new machine ;-) Bastien From: Wendell Frohwein [EMAIL PROTECTED] To: 'Bastien Koert' [EMAIL PROTECTED],[EMAIL PROTECTED] CC: php-db@lists.php.net Subject: RE: [PHP-DB] Slow Query Date: Thu, 13 Jan 2005 13:21:33 -0800 Thank You Bastien. My newest Vision that I had about taking out a step in the process has failed. Mainly because of the script that determines the radius. Since I was going to go off of the agents zipcode coverage area (to save a step), and not the zipcode table containing 45,000 + entry's. If an order was placed by a client with lets say the zip code 90606, and there was no agent in the entire system that had this exact zip code in there coverage area, the radius code would error out and return no matches. Even though in the 2-5 mile radius of 90606 there is matching agents. It needs to see that first zip codes (90606) longitude and latitude to even begin the radius function. So now I was bumped again. I rewrote some of my code to be a little more streamlined. So I began testing orders: 50, 100, 200, and 400. The time it takes to assign orders to agents is really had to determine because it is based on how many agents and how many zipcodes in those agents coverage area. With 400 orders within a heavy populated area it takes as much time as 127 seconds to process. If there are fewer zip codes in an area such as mid east / west it takes as little time as 11 seconds to process. When I start the assignment of orders I open up a shell via ssh, monitor the system using the top command. Mysqld spikes between 55% and 99% cpu usage the entire time of the assignment process. Where it says User CPU usage its between 70% and 99% cpu usage. And finally where it says System CPU Usage, it rarely goes over 3% - 5%. The server is not mine, but one I manage for the company. I used dmesg to find out that the server this site is running on is a 700mhz celeron coppermine, 128MB of ram, 10gig western digital drive. So with this in mind, I think my problem behind slow queries is affected in other areas other then the script itself. Thank you all very much for all your help. -Wendell Frohwein -Original Message- From: Bastien Koert [mailto:[EMAIL PROTECTED] Sent: Thursday, January 13, 2005 10:04 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: php-db@lists.php.net Subject: RE: [PHP-DB] Slow Query Hi Wendell, What you've proposed is not a bad solution. There is some initial work to set up the stuff for the existing agents, but if you define a limit to the range that the agent works in, then you can take the result stuff it into a comma delimited string and place that into the agent_zip_codes field...then the realtime time query is a simple IN (zip1, zip2, zipN) statement and should be faster Bastien From: Wendell Frohwein [EMAIL PROTECTED] To: 'graeme' [EMAIL PROTECTED] CC: php-db@lists.php.net Subject: RE: [PHP-DB] Slow Query Date: Thu, 13 Jan 2005 00:30:34 -0800 Thank you Graeme. But unfortunately, there are a 700 + agents. This number keeps growing every day as well. I had a vision of another idea. I don't know how much time it will save. In the table that stores all the agents zipcodes that they cover, I added longitude and latitude to the table. So when my zip code radius function kicks in, it will find agents with there respective zip code. Before it would take the property zip, query the zipcodes table with over 42,000 zip codes, then put those in an array, then search for agents from there. The way I see it, I killed one step in the process. But at the time of me writing this letter I am still trying to get it to work. If I do, I will post up some numbers to see how much faster it is. But I am still looking for a better way to do it. Thanks once again to everyone. -Wendell Frohwein -Original Message- From: graeme [mailto:[EMAIL PROTECTED] Sent: Thursday, January 13, 2005 12:02 AM To: Wendell Frohwein Cc: php-db@lists.php.net Subject: Re: [PHP-DB] Slow Query How many agents do you have? If the number of agents is small then you could set up a temp table which has a link to the agent, the client, and a calculation of the distance between the two. Then do your search on this temp table. Once you have the answer you want delete the records for this client. (that should allow for more than one client entering data at the same time, although you may want to properly think that scenario through) graeme. Wendell Frohwein wrote: First of all I would like to thank anyone who lends a hand in this matter. Here is what im working with. Redhat 9, PHP 5.0.2, Apache/2.0.50, MySQL 4.1.8-standard Binary Installation for pc-linux-i686, OpenSSL 0.9.7d, gcc version 3.2.2. PHP compiled with mysql, and mysqli capability. This is how the script works: The client submits a property for an appraisal. Based on the appraisal type and property zip code, It searches the database for agents / appraisers with the zip code in question (property zip code) in there
[PHP-DB] Input ++90 causing problems
It appears that the code below in short has the following problematic strings: ++90 ++90-212- gives 212- on my test page below: error2.htm. A clue might be that a search on google turns up Arabic unicode, and the input here was done in Turkey. check the link: http://www.londonriverside.co.uk/error2.htm and let me know if it appears the same to you or is a function of my computer, which includes Japanese libraries. (In order to send this message I need to choose unicode formatting.) ++90 ++90 gives ++90 ++90 on error3.htm - and is correct The string ++90 came from a web input form, where someone was putting in their phone number. It was stored in a database and retrieved onto a web page, all using php, on which page it screwed up the css and caused unusual javascript errors. Although when the same person input the same phone number on the same form again, the same problem did not occur all the time but did re-occur at least twice. I cut down the HTML and finally found these few figures seemed to be the cause, though if I used my HTML editor to applyt auto-formatting to the page the error did not occur. Also if I simply deleted the ++90 characters and typed them in again and uploaded that, there were no errors. Confusingly, href links to other pages requiring a query to be run on the same record in the database - although it does not require to retrieve and show the phone number on the htm page but does use the index reference of the record - fails to retrieve any information for the record, eg my dates just default to 01/01/1970 erroneously and other info is retrieved on the record, in this case there is no css problem or javascript error in the static HTML, just no data to show within the page. Also note that when I get into the table and cut and paste all the info to a new record, the new record works - ie I can retrieve it with same tel numbers and everything works. Is there something about this string ++90 that is problematic, possibly in relation to being sent from an internet form initially? If it's simply a familiar error from Arabic unicode perhaps I should be filtering this out on all input pages? are there other such problematic strings? what am I searching for if I search for good input filtering for web input forms? John I did the following test pages: error2.htm: html head titletest/title LINK href=styles/test.css type=text/css rel=stylesheet /head body text=#00 leftmargin=0 topmargin=0 marginwidth=0 marginheight=0 bgcolor=#ff table width=1000 border=1 cellspacing=0 cellpadding=0 trtd class=textset3 colspan=12 ++90 ++90-212- /td/tr/table /body /html error3.htm: html head titletest/title LINK href=styles/enquiries_css.css type=text/css rel=stylesheet /head body text=#00 leftmargin=0 topmargin=0 marginwidth=0 marginheight=0 bgcolor=#ff table width=1000 border=1 cellspacing=0 cellpadding=0 trtd class=textset3 colspan=12 ++90 ++90 /td/tr/table /body /html
