Subject | Re: [IBO] Paradox Comparison |
---|---|
Author | nevillerichards |
Post date | 2003-11-15T18:41:02Z |
I had originally used the "5 minute" conversion recommended on the IBObjects
site using GReplace.
BDE TTable being converted to TIBOTable, etc.
The table I am importing contains about 300,00 records in two columns: and 8
character (UK) postcode, and an index of deprivation (floating).
This is the table spec:
/* Table: UPLIFTI, Owner: SYSDBA */
CREATE TABLE "UPLIFTI"
(
"POSTCODE" VARCHAR(8) CHARACTER SET WIN1252 NOT NULL,
"UPLIFT" FLOAT,
PRIMARY KEY ("POSTCODE")
);
The original code converted from the Paradox app which imported into the
Paradox table in 3 minutes is like:
UplifTIBOTable.SetKey;
UplifTIBOTable.FieldbyName('PostCode').asstring := postcode;
if not UplifTIBOTable.GotoKey then
begin
UplifTIBOTable.append;
UplifTIBOTable.FieldbyName('PostCode').asstring :=
postcode;
end else UplifTIBOTable.edit;
UplifTIBOTable.FieldbyName('Uplift').asfloat := deprivation;
UplifTIBOTable.post;
next;
// if the record didn't exist, then create it, otherwise, edit what is
there.
The exact same code in the IBO version took approximately 3 hours (I got fed
up of timing exactly).
Clearly, this idiom of programming the data transfer which works fine with
Paradox through TTable is not viable with IBO through TIBOTable.
There must be a better method, and you have suggested TIB_DSQL, which I need
to look at.
Any pointers to how to proceed??
Thanks, Neville
site using GReplace.
BDE TTable being converted to TIBOTable, etc.
The table I am importing contains about 300,00 records in two columns: and 8
character (UK) postcode, and an index of deprivation (floating).
This is the table spec:
/* Table: UPLIFTI, Owner: SYSDBA */
CREATE TABLE "UPLIFTI"
(
"POSTCODE" VARCHAR(8) CHARACTER SET WIN1252 NOT NULL,
"UPLIFT" FLOAT,
PRIMARY KEY ("POSTCODE")
);
The original code converted from the Paradox app which imported into the
Paradox table in 3 minutes is like:
UplifTIBOTable.SetKey;
UplifTIBOTable.FieldbyName('PostCode').asstring := postcode;
if not UplifTIBOTable.GotoKey then
begin
UplifTIBOTable.append;
UplifTIBOTable.FieldbyName('PostCode').asstring :=
postcode;
end else UplifTIBOTable.edit;
UplifTIBOTable.FieldbyName('Uplift').asfloat := deprivation;
UplifTIBOTable.post;
next;
// if the record didn't exist, then create it, otherwise, edit what is
there.
The exact same code in the IBO version took approximately 3 hours (I got fed
up of timing exactly).
Clearly, this idiom of programming the data transfer which works fine with
Paradox through TTable is not viable with IBO through TIBOTable.
There must be a better method, and you have suggested TIB_DSQL, which I need
to look at.
Any pointers to how to proceed??
Thanks, Neville
> On Fri, 14 Nov 2003 19:57:40 +0000 (UTC), nevillerichards wrote:
>
> > I am converting a large project from Paradox to IBO (using the TDataset
> > equivalents).
> > The software imports and processes large quantities of ASCII data.
> > So far, the IBO version seems to run at about 1/5 the speed of the
> > original Paradox. I am sure that this isn't how it was supposed to be!
> > Does anyone know of any obvious pitfalls that people usually drop into?
>
> In some situations, nothing (well, hardly anything) can beat a desktop
> database like Paradox for speed. As Lucas said, C/S databases is about
> more than speed - robustness is just one point.
>
> When importing, do use the TIB_DSQL (which you prepare just once).
> After the import, there are new pitfalls to avoid ... - just ask here.
>
>
> Regards,
> Aage J.
>
>