Hi All,

This is probably me again. But I use bde in a unique way I guess in some
of my apps meant to emulate an old dos database system, it works in bde
apps, but not ibo emulation out of the box.


First I start with an empty result set, found by doing something like this
(this is greatly simplified of course, but my driver numbers all all
positive integers):

select driver_no, lname, fname from drivers where driver_no = -1;

I used the dbedit fields for simple QBE/edit fields. If you want to so
a simple search, you can type in a blank dbedit (which starts an auto
insert)in the empty query set.

When you hit enter (or the find button below),it something like this
(actually it fills two arrays one for data and one for search field
related to the data):

String MyData;
String MyField;

Mydata = FairData->DriverQuery1DRIVER_NO->AsString;
MyField = "driver_no";

The end result of this assignment in a bde app is the data I just put in
the field even though I have not yet committed it. The end result of this
assignment in ibo bde emulation is NULL for the field.

I then throw away the insert, clear and rewrite the query using Mydata and
Myfield in the where statement, and open the query....and do whatever I
wanted with the result set.

I figure its got to do with the differences in the actual internal working
of the bde and ibo bde emulation. Both the bde and ibo databases are
using read committed. I suppose I can always use the DBEdits Text field
to get the data or something else at the datasource level might be more
appropriate (what would you guys consider proper)...but why does this not
work?

---

I also do some programatic use of this "feature" of the bde. So I might
do an append or edit FairData->DriverQuery1->Append();

Then do something like FairData->DriverQuery1DRIVER_NO->AsInteger = 99;

and before committing do a check like:

if (FairData->DriverQuery1DRIVER_NO->AsInteger < 1000)
{
///something done here
}

I was worried that this type code would also not work...but it appears
that this type of code still does work ok in my initial tests. So it
seems likely to be something in the way iboquery and the datasource/dbedit
interact (which is obviously different than the way bde interacts with
them).

thanks
Randal Carpenter