Subject | Re: [IBO] BDE Emulation problem with cached updates insert |
---|---|
Author | Helen Borrie |
Post date | 2007-03-12T22:44:46Z |
At 09:15 AM 13/03/2007, you wrote:
demo of it using the employee database.
The UpdateObject functionality *is* built into the IBODataset, via
the EditSQL, InsertSQL and DeleteSQL properties, as you already
discovered. You don't require an UpdateObject, it's just there to
make it simpler for the initial conversion.
If you have only a single-table query for your SQL, you don't have to
create your own xxxxSQL properties at all (provided the KeyLinks are
correct, of course). Just set RequestLive true and IBO will create
them for you automatically.
Possibly the key thing (unintentional pun) that you might have missed
is KeyLinks. For a single-table dataset you can set
KeyLinksAutoDefine and IBO will try to work out the unique key for
the dataset - provided of course that your dataset records are
unique. You should at least check the KeyLinks to see whether IBO
got it right. For example, sometimes it doesn't, if you have a
composite PK. Myself, I always define the KeyLinks myself.
For joined sets, you should always enter the K/L manually.
KeyLinks are right.
components (TIB_*). If you are using the TIBO* data access
components then you just continue to use whatever controls you used before.
You *can* share a BDE connection with a TIBODatabase using the
dbHandleShared property. There is an example in the help.
Helen
>Hi All,Maybe....if this is important to you, perhaps you could make a simple
>
>I have a couple of questions:
>
>1. I just installed ibo 4.7 build 16 into cpp builder 6 enterprise, which
>is the first time I have tried 4.x for bde replacement. I followed the
>instructions for search and replace for my bde components and fired up my
>application.
>
>What I found is that it comes up with
>EIB_DatasetError: Cannot Insert a new Row
>
>During any insert attempt (manual or automatic) all my important IBOQuery
>based queries. I looked in the IBOUpdates related for each one, and the
>insert query is there. At that point I copied my insert query from an
>IBOUpdates component directly into the IBOQuery InsertSQL, and the problem
>goes away.
>
>So is the IBOUpdates object being ignored due to a bug
demo of it using the employee database.
The UpdateObject functionality *is* built into the IBODataset, via
the EditSQL, InsertSQL and DeleteSQL properties, as you already
discovered. You don't require an UpdateObject, it's just there to
make it simpler for the initial conversion.
If you have only a single-table query for your SQL, you don't have to
create your own xxxxSQL properties at all (provided the KeyLinks are
correct, of course). Just set RequestLive true and IBO will create
them for you automatically.
Possibly the key thing (unintentional pun) that you might have missed
is KeyLinks. For a single-table dataset you can set
KeyLinksAutoDefine and IBO will try to work out the unique key for
the dataset - provided of course that your dataset records are
unique. You should at least check the KeyLinks to see whether IBO
got it right. For example, sometimes it doesn't, if you have a
composite PK. Myself, I always define the KeyLinks myself.
For joined sets, you should always enter the K/L manually.
>or did I missLike everything in IBO, clientdatasets will behave properly if the
>something in my extensive skim reading? Can I expect clientdatasets to
>behave any better?
KeyLinks are right.
>2. If I decide against converting bde stuff to ibo via the emulationThe native IBO controls work *only* with the native IBO data access
>components, can I expect to be able to run native ibo objects/controls in
>the application beside bde objects/controls without any strangeness going
>on?
components (TIB_*). If you are using the TIBO* data access
components then you just continue to use whatever controls you used before.
You *can* share a BDE connection with a TIBODatabase using the
dbHandleShared property. There is an example in the help.
Helen