Hi Helen,

Thanks for replying, with help from "tibotaka" in the previous
message i have actually made the system behave as it always did
before with version 4.2.I(corrected).

Its always difficult when in a blind panic to think clearly and to
publicise the 100's of changes that have been made in an attempt to
find a solution. I am sorry if this has "fogged" your view. and do
very much appreciate your efforts in resolving this for me.

With regards to your previous posting:-

" I'm also unclear by what you mean by "crashes".
==================================================
Sorry meant to state the the dialog pops up saying that, "TIBOTable
Client: Field CUSTREF not found".


"You have a TIBOTable for this so it may take some time"
========================================================
This implies that i'm using something that is not the optimum for
the task, to rewrite the whole application using TIBOQuery would be
a feat in it's self, or learn how the "native" IBO components work
would put me out of business, We do try and write code as
efficiently as possibly, but we always know that someone will say
that C++ is better, or Asembler is better still..;-), I'd like to
know what you'd reccommend we use.

"ther Never Was a Version 4.20i"
=================================
Im sorry in the panic i wrote 4.20i and should have written 4.2i.

"It has been a long time since 4.2"
===================================
I appreciate that 4.2 was a long time ago but it has the "Features"
that we would expect from a "normal" detail table connection, where
by changing the table name, causes the dataset to reconstruct all
it "knows" about the table. This is why the 4.2i version works so
well. It has never been an issue with all our other projects due to
the fact that each table is dedicated to a database table, and never
jumps about the database looking at different tables. This is why in
this application it has just surfaced.


"it's a fact that, if you don't explicitly create persistent fields"
===================================================================
I can understand that Persistant fields maybe created in the
background for Delphi to do its "Thing" regarding Grids and the
like, but cant quite get my head around why the table only
makes "Persistant" fields when data is written through it, I can
easily jump around 1000's of tables without a hitch until i write to
one, at that point the fields become persistent.

"Try to lose the habit of treating the SQL.Text property of a query
as writable"
===================================================================
I dont recal ever writing to the SQL.Text property in my life, as
this seems against all the obvious coding principles we use. In my
example I have made a reference to the SQL.text property but only in
the memo.lines.add( call to display what the whole SQL is currently
set to, so I could see if the SQL was actually following
the .Tablename, which of course it was.

Adn Finally.....The Solution.

IBOQueryClient.Open;
IBOQueryServer.Open;

IBOTableClient.Fields.Clear; <<< SOLUTION TO FIX PROBLEM
IBOTableClient.Open;

IBOTableServer.Fields.Clear; <<< SOLUTION TO FIX PROBLEM
IBOTableServer.Open;

We also found that TIBOTable.Unprepare makes absolutely no
difference at all, strangly enough, which surprised us as well
thinking that you had "hit the nail on the head" so to speak.

We are a little worried that the method you kindly showed us
regarding the closing and opening of the master - detail tables
indicates that we should maybe not using "on form" components (Eg
TIBOTable, TIBOQuery) but actually creating these "on-the-fly" thus
ensuring that all the fields and links are destroyed, is this
correct?


Thanks Again Helen, by the way I have your excellent book and must
read it some more.

Cheers

Colin Coleman

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
> At 11:32 AM 2/04/2005 +0000, you wrote:
>
>
> >And some more investigation reveals:-
> >
> >I have now built a clean Xp machine loaded Delphi7,IBO 4.20I ,And
a
> >host of other components same as my main development machine, and
> >have copied the whole project from the main machine to the new PC
> >and then compiled the project using the DOS compiler, so i dont
> >change ANYTHING in the project and guess what it all Works
> >perfectly!. (Using IBO4.20i)
> >
> >It Appears that whenever the IBOtable component gets written to it
> >seems to lock the fields into its memory somewhere and thats it,
it
> >only wants to use for these fields forever once written, as
though i
> >have created persistant fields, if this is the case how do i
rectify
> >it, ive tried adding this following code during the table open and
> >it still crashes.
> >
> > sTablename := IBOTableClient.TableName ; // Eg CUSTOMERS
> > FormMainReplicate.Memo1.lines.add(sTablename+'
> > Before='+IBOTableClient.SQL.Text +
> > ' FieldCount ='+IntToStr(IBOTableClient.FieldCount));
> > IBOTableClient.SQL.Clear;
> > IBOTableClient.FieldDefs.Clear;
> > IBOTableClient.MasterSource := DataSourceQClient;
> > IBOTableClient.TableName := sTablename ;
> > FormMainReplicate.Memo1.lines.add(sTablename+ 'After='
> > +IBOTableClient.SQL.Text+
> > ' FieldCount =' +
> > IntToStr(IBOTableClient.FieldCount));
> > Try
> > IBOTableClient.Open;
> > Except
> > FormMainReplicate.Memo1.lines.add('*** CRASHED *** '+
> > sTablename+' ='+
> > IBOTableClient.SQL.Text+' FieldCount ='+
> > IntToStr(IBOTableClient.FieldCount));
> > Exit;
> > End;
> >
> >If you could help me with this i would be very grateful as i seem
to
> >be getting nowhere except being able to pont the finger at IBO
4.5Ai
> >as the root cause.
> >
> >Thanks Jason or anyone that can help me..
>
> Well, I must confess I'm in a bit of a fog about what you're doing
here and
> I'm also unclear by what you mean by "crashes".
>
> A possible flaw I see with the various pieces of code you've
offered is
> your assumption that the master set is actually squeaky-clean and
prepared
> at the time you try to reference it through the MasterSource and
> MasterFields properties. If this binding hasn't been done yet,
then the
> TIBOTable has no way to know which rows it is supposed to
display. That
> should cause an AV.
>
> The sequence of events when swapping the tables ought to be:
> 1. Close the detail set. You have a TIBOTable for this so it may
take
> some time.
> 2. Clear the MasterFields property of the detail set.
> 3. Set the MasterSource to nil.
> 4. Set the datasource that points to the detail set to nil.
> 5. Clear the Fields object of the detail set.
> 6. Clear the SQL (or Tablename) property of the detail set.
> 7. Close the master set.
> 8. Set the datasource that points to the master set to nil.
> 9. Clear the Fields object and the SQL property of the master set.
>
>
> Now, go back and reconstruct the sets:
> 1. Set the SQL property of the master set.
> 2. Set the datasource that points to the master set.
> 3. Prepare the master set.
> 4. Set the SQL (or Tablename) property of the detail set.
> 5. Set the Mastersource property of the detail set.
> 6. Set the Masterfields property of the detail set.
> 7. Open the master set. This should prepare and open the detail
set but
> you might need to test whether it's active and open it if not.
>
> You can actually track this sequence of events yourself in the
IDE, by
> going through and doing each of these actions manually.
>
> Also I can't work out which old version of IBO you were coming
from. There
> never was a "4.2Oi". The last release 4.2 version was 4.2Ie in
June 2003
> (although there was a 4.2Ie_to_f test patch in July that year).
>
> Much has changed since then, especially with the buffering of rows
in the
> TIBOTable. It has been a long time since 4.2 but it's very
probable that
> some of those changes are forcing you to pay closer attention to
the
> sequence of events in field bindings.
>
> A possible place for attention is the state of your datasets when
the form
> opens. There is a TIB_Session setting StoreActive that's there
for use
> when transitioning from the BDE: if you inadvertently left this
True when
> you did your initial conversion, it could be biting you now.
Could you
> check in the DFM file to see what that is set to? It should be
false (the
> default) and datasets should be opened when required and -
importantly - in
> the required order to avoid having unreferenced field objects (or
> TIB_Column objects in the InternalDataset). Obviously,
something's going
> to blow if you have those - either lying around from a previous
> instantiation or not bound because things happened in the wrong
order.
>
> Re your theory about the TIBOTable and TIBOQuery
storing "something
> persistent" - it's a fact that, if you don't explicitly create
persistent
> fields for the TDataset classes, then Delphi does it anyway, at
> runtime. So, if you are going to de-reference the output set, you
need to
> de-reference any field objects that Delphi created for its own
> purposes. As far as the InternalDataset (a TIB_BDataset) is
concerned,
> it's enough to unprepare the dataset, which will happen when you
clear the
> SQL.
>
> Try to lose the habit of treating the SQL.Text property of a query
as
> writable. The "clean-through" way is to use the methods of the
SQL
> property, viz. Clear (to clean and unprepare) and Add (to set the
> statement). When you're using ad hoc run-time SQL, assembling it
from bits
> and pieces of variables as you are, it's a lot easier to see where
you are
> going if you lay things out formally in chunks.
>
> I know none of this puts a finger right on the button of what's
different
> now, but hopefully it can give you some places to look where your
old code
> needs tightening up.
>
> Helen