Error 244 Fetch Error
Michael Todd
The error code documentation points to corrupted files but online.log shows no indication of this error. One of our developers thinks it may be due to a low resource parameter on the RS/6000 990 server but we don't have a clue as to which one if that indeed is the problem.
Any ideas what could be causing the problem?
Thanks in advance.
Marv Todd, Wang Labs.
mt...@shore.net
--
Michael Todd
mt...@shore.net
Dan Madvig - Bethel College & Sem.
> Error 244 (Could not do a physical order read to fetch next row) has been occurring more frequently in our application. It comes up during a fetch next row call. When we get the error, that particular query is incomplete; however subsequent queries work fine. We are even able to repeat the same query and it work fine on the second try.
>
> Any ideas what could be causing the problem?
>
Are you using SACEGO? As I understand it, there's a BUG in SACEGO. It won't
do DIRTY READs. Thus when someone has a row locked, your query burps.
--
Dan Madvig e-mail: d-ma...@bethel.edu
Bethel College & Seminary phone: (612) 638-6414
3900 Bethel Drive fax: (612) 638-6001
St. Paul, MN 55112
If it weren't for my ignorance,
Your brilliance would be of no use.
Jonathan Leffler
>Date: Wed, 19 Apr 95 16:35:12 CDT
>X-Informix-List-Id: <list.6033>
>
>> Error 244 (Could not do a physical order read to fetch next row) has
>> been occurring more frequently in our application. It comes up during a
>> fetch next row call. When we get the error, that particular query is
>> incomplete; however subsequent queries work fine. We are even able to
>> repeat the same query and it work fine on the second try.
The error is typically transient -- someone else had a lock on something
at an inconvenient moment. A rerun will therefore seldom run foul of the
same error on the same row.
>> Any ideas what could be causing the problem?
>
>Are you using SACEGO? As I understand it, there's a BUG in SACEGO. It
>won't do DIRTY READs. Thus when someone has a row locked, your query
>burps.
Depending on the version of ISQL in use, SACEGO uses the SACEISOL
environment variable to control the isolation. With versions 4.12, 4.13
and 6.00, 6.01 (and any future versions), the value can be any of the
isolation levels 'committed read', 'repeatable read', 'cursor stability' or
'dirty read'. In 4.11, the only value was 'dirty read'. I am not certain
whether it was available in either 4.00 or 4.10, but I think not.
Yours,
Jonathan Leffler (jo...@informix.com) #include <disclaimer.h>
June Tong
: Error 244 (Could not do a physical order read to fetch next row) has been occurring more frequently in our application. It comes up during a fetch next row call. When we get the error, that particular query is incomplete; however subsequent queries work fine. We are even able to repeat the same query and it work fine on the second try.
It's probably because the row is locked the first time you tried to access it.
Which documentation are you looking at? I think it should say something like:
Unless the ISAM error points to another cause...
In this case, your ISAM error should be something like -107: Record is locked.
Also, I think that the fact that you are getting "Could not do a physical
order read" means that you are doing a sequential scan, not using an index.
In this case, it may not be the actual row you are trying to read which is
locked, it may be another row that you are trying to read PAST.
June
---- June Tong Informix Asia/Pacific ----
---- On-Loan Engineer Singapore ----
---- Location-du-jour: Bangkok ----
---- ju...@informix.com (65) 298-1716 ----
Jonathan Crawford @ ArkTech
: Error 244 (Could not do a physical order read to fetch next row) has been
: occurring more frequently in our application. It comes up during a fetch
: next row call. When we get the error, that particular query is incomplete;
: however subsequent queries work fine. We are even able to repeat the same
: query and it work fine on the second try.
<snip>
: Thanks in advance.
: Marv Todd, Wang Labs.
: mt...@shore.net
: --
: Michael Todd
: mt...@shore.net
Actually, we had that problem appear before we discovered the DBTEMP
environment variable. Our /tmp partition is fairly small, and, as the
default location that Informix 5.04 uses for temporary sort files, it
filled up rapidly when we did certain selects on >750,000 records.
Creating appropriate indexes and setting DBTEMP made the problem go away
for us.
Hope this helps!
-- Jonathan Crawford
Ark Technologies, Inc.
Sally Woolrich
mt...@shore.net "Michael Todd" writes:
> Error 244 (Could not do a physical order read to fetch next row) has been
> occurring more frequently in our application. It comes up during a fetch next
> row call. When we get the error, that particular query is incomplete; however
> subsequent queries work fine. We are even able to repeat the same query and
> it work fine on the second try.
<snip>
Is this page-locking causing the problem? (instead of row-locking)
--
============================================================================
Sally Woolrich | This mail contains my personal
sa...@excelsis.demon.co.uk | views not those of my employer!
============================================================================
Gnana1
Try to check sqlca.sqlcode after every select/fetch statement, and loop
after
2 seconds wait. This way you may not see programs crashing abruptly.
I am almost certain that your code needs fine tuning for efficiency, and
the transaction based commit/rollbacks are taking a long long time to
finish up. A more permanent fix for your problem is not easy to achieve
unless you improve your code.
Thanx.
Ravi.