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
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!?
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
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
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 ?
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
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
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
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:
