On Tue, 13 Mar 2007, Helen Borrie wrote:

> Maybe....if this is important to you, perhaps you could make a simple
> demo of it using the employee database.

Hi Helen,

I did, and it worked ok...but I used no joins in it, more on that below...

>
> 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.
>

I thought I noticed something quite interesting and almost blamed my
application itself, but this answered it. On single table queries it
worked ok without moving the insert...I assume now its because ibo was
smart enough on those to take care of it on its own. Its the queries with
join(s) that need to edit that are the problem. I guess I will just
search for all the TUpdateSQL and cut and paste into the proper places in
the IBOQueries since that would be cleaner anyway. Most of my queries are
reports anyway, so the number of these actual update objects are not that
many.

> 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.
>

Well that fixes the problem...I knew I was supposed to, but I also noticed
on some queries it guessed it correctly so I thought it was not really
necessary after that...guess thats what I get for thinking :). I think I
will define all my KeyLinks too to avoid other such problems. Maybe the
InsertSQL gave it enough info to guess the keylink on its own. I think I
will still get rid of the UpdatesSQLs cause I have been using IBX some and
have taken a liking to that stuff being right there in the query itself.

> For joined sets, you should always enter the K/L manually.
>
>> or did I miss
>> something in my extensive skim reading? Can I expect clientdatasets to
>> behave any better?
>
> Like everything in IBO, clientdatasets will behave properly if the
> KeyLinks are right.
>
>> 2. If I decide against converting bde stuff to ibo via the emulation
>> 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?
>
> The native IBO controls work *only* with the native IBO data access
> 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
>

Ah...I guess I got some reading to do...maybe I need to look before I leap
next time...nah. Any suggestions for good ibo reading would be
appreciated. Of course now I am in the thick of it, so I might as well
keep poking at it...I got plenty of time, and multiple backups of the
before conversion code if I decide to go the shared route. I see another
problem...yea its probably me, but I am gonna start another thread for
that one since I was so specific on the subject of this one.

thanks much
Randal Carpenter


PS: Its interesting to see what everyone is doing now. I don't know if
you remember me, but I was quite active on the lists back when ib was
first being opensourced and really enjoyed participating actively but then
life intervened. I am just not getting to the point where I have some
free time at work/home, now it seems I have a lot of catching up to do.