Re: Search by index vs. sequential scan
cr*p. Thanks for the heads up - I will refrain from using the web front end. cheers j. ----- Original Message ----- From: "Jonathan Leffler" <jleffler@earthlink.net> To: <informix-list@iiug.org> Sent: Wednesday, May 21, 2003 11:30 PM Subject: Re: Search by index vs. sequential scan > vze2qjg5@verizon.net wrote: > > This is a multi-part message in MIME format. > > > > ------=____1053523979015_vjCTQzO,Lm > > Content-Type: text/plain; charset=ISO-8859-1 > > Content-Transfer-Encoding: 7bit > > > > > > If you ask me (and I gues you sort of did) - this is a design issue. You are relying on the database to lock the rows in question to prevent another process from grabbing it. Change you're NO-OP statement to update the value to 'R'unning or something - then there is no lock in use and the problem goes away. The second process won't grab it because the status flag is no longer NULL. When the daemon is done it goes back and stamps the row as complete. > > > > cheers > > j. > > Mr Parker - not content with posting MIME, you're also posting base64 > encoded messages. Not good. That's twice today, too. > [deletia] > > > > > > -- > Jonathan Leffler #include <disclaimer.h> > Email: jleffler@earthlink.net, jleffler@us.ibm.com > Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/ > >
"Jack Parker" <vze2qjg5@verizon.net> wrote in message news:baini7$aup$1@terabinaries.xmission.com... > cr*p. > Thanks for the heads up - I will refrain from using the web front end. > cheers > j. > ----- Original Message ----- > From: "Jonathan Leffler" <jleffler@earthlink.net> > To: <informix-list@iiug.org> > Sent: Wednesday, May 21, 2003 11:30 PM > Subject: Re: Search by index vs. sequential scan > > > vze2qjg5@verizon.net wrote: > > > This is a multi-part message in MIME format. > > > > > > ------=____1053523979015_vjCTQzO,Lm > > > Content-Type: text/plain; charset=ISO-8859-1 > > > Content-Transfer-Encoding: 7bit > > > > > > > > > If you ask me (and I gues you sort of did) - this is a design issue. > You are relying on the database to lock the rows in question to prevent > another process from grabbing it. Change you're NO-OP statement to update > the value to 'R'unning or something - then there is no lock in use and the > problem goes away. The second process won't grab it because the status flag > is no longer NULL. When the daemon is done it goes back and stamps the row > as complete. > > > > > > cheers > > > j. > > > > Mr Parker - not content with posting MIME, you're also posting base64 > > encoded messages. Not good. That's twice today, too. Geez, Jonathan, don't encourage Jack by calling him Mr. Parker...