physical order read to fetch next row error
Posted in 2011
Topics: Connectivity: ODBC / JDBC / .NET, Data Types & Schema Design, Third-Party Tools & Monitoring
Hi,
I have the e-governance application. I am using Informix 11.70 with Visual
Basic 6.0. I am using a Property Tax module. In that module i enter the data
in data entry form & save.
One form for data entry & multiple tables for saving data. See attached image
1.JPG
At a time minimum 5 users enter the data on same time in data entry form.
Used below tables -
List of Tables:
1. PropertyOwner
2. PropertyMaster
3. PropertyInfo
4. PTax_GharTaxes
5. PTax_OldrateInfo
6. PTax_ApilNew
7. PTax_VyajNotice
When i click on Save button it gives an error
[Informix][Informix ODBC Driver][Informix]Could not do a physical-order read
to fetch next row. sqlerrnum(propertyowner)
See below the dbschema :=
create table "informix".propertyinfo
(
gharno nvarchar(90) not null ,
sr integer not null ,
floor nvarchar(10),
huser nvarchar(250),
length float,
width float,
yrent money(19,2),
huse nvarchar(250),
propertycode integer,
husage nvarchar(50),
building "informix".boolean,
rental "informix".boolean,
finyr nvarchar(9),
apilchange integer not null ,
legalybld integer not null ,
area float,
septic integer,
buildyr nvarchar(50),
classid integer
);
create table "informix".propertyowner
(
gharno nvarchar(90),
owner nvarchar(255),
owneraddr nvarchar(255),
sr integer,
finyr nvarchar(9) not null ,
userid nvarchar(10)
);
create table "informix".propertymaster
(
srno integer not null ,
zoneno integer,
gharno nvarchar(90),
wardno nvarchar(10) not null ,
ssno nvarchar(50),
rsno nvarchar(50),
yearlyrent money(18,2),
finyr nvarchar(9),
tdate date,
gobar integer,
sefty integer,
built nvarchar(25),
electricity integer,
water integer,
pipes nvarchar(10),
yr integer,
yrs nvarchar(10),
ngpprop integer,
zeroprop integer,
bhog nchar(500),
appyesno integer not null ,
appname nvarchar(150) not null ,
blockid integer,
locationid integer,
localityid integer,
drainage integer,
waterharvest integer,
userid nvarchar(10),
rvsnyr integer,
rvsnyear nvarchar(10),
newgharno nvarchar(90)
);
create table "informix".ptax_ghartaxes
(
srno integer not null ,
gharno nvarchar(90) not null ,
wardno nvarchar(50) not null ,
zoneno integer not null ,
doc_date date not null ,
usesname nvarchar(150) not null ,
taxid integer not null ,
taxname nvarchar(50) not null ,
taxamt float not null ,
finyr nvarchar(9) not null
);
create table "informix".ptax_oldrateinfo
(
srno integer not null ,
gharno nvarchar(90) not null ,
wardno nvarchar(50) not null ,
zoneno integer not null ,
doc_date date,
usesname nvarchar(150) not null ,
areao float not null ,
typeo nvarchar(150) not null ,
rento float not null ,
norento float not null ,
vadho float not null ,
oldrento float not null ,
tenpero float not null ,
totaloldrento float not null ,
finyr nvarchar(9) not null ,
oldspace float not null ,
oldspacerent float not null
);
create table "informix".ptax_apilnew
(
gharno nvarchar(90) not null ,
newrent integer not null ,
discnew float not null ,
oldrent integer not null ,
discold float not null ,
finyr nvarchar(9) not null ,
newsetting nvarchar(50),
oldsetting nvarchar(50),
newvarshikmulya float,
oldvarshikmulya float
);
create table "informix".ptax_vyajnotice
(
gharno nvarchar(90) not null ,
wardno nvarchar(50) not null ,
vyaj float not null ,
noticefee float not null ,
warrentfee float not null ,
finyr nvarchar(9) not null
);
So please give solution.
Thanks
Hy, if I see it right you have no field in your tables that represent an index with no double values. ODBC drivers request at least one field that represent a clear Id of your row, otherwise you get strange effects while writing back to a table, reading usually works... I strongly recommend a serial field in each table with an index on it. I named them all idxodbc ;-) Mfg Joerg Volz Am 07.11.2011 um 05:46 schrieb "SANDIP SHINDE" <sandipvshinde1983@gmail.com>: > null ,
you mention 5 users updating at same time I wonder if it is a locking issue ?
An onstat -u will show you if any locks happening at time of error
you mention 5 users updating at same time I wonder if it is a locking issue ?
An onstat -u will show you if any locks happening at time of error