Subject Re: [IBO] dssEdit
Author bullardjuk <>
--- In, Helen Borrie <helebor@t...> wrote:
> At 07:22 PM 25/01/2003 +0000, you wrote:
> >I am thoroughly confused ! (As usual).
> >
> >What is he significance of the various dssEdit, dssInsert etc
> >as the state of a dataset ?
> >How are they caused ?
> Does it help to know that dssEdit, etc. in the native IBO dataset
> equivalent to dsEdit in the VCL datasets? dss* are dataset states -
> they apply to datasets.
> A dataset is always in one state. A state change occurs as the
result of a
> sequence of events. That sequence is triggered off by a call to a
> The neutral state is dssBrowse. So, if you want to think of it
> simplistically, a call to the dataset's Edit method causes the
dataset to
> transit through from dssBrowse to dssEdit - unless the dataset
cursor is at
> the end of the dataset (EOF), in which case it will transit through
> dssInsert instead.
> I use the term "transit" because it isn't like simply flicking a
> switch. The dataset has to check various conditions and perform
> actions before the state change can be considered "ready to go".
Once all
> of those things are done, the state change happens.
> >And which comes first.
> The SQL statement ---
> defines the interchange that you want to happen between the client
and the
> server. A SELECT statement is a specification for a dataset. An
> UPDATE or DELETE statement doesn't specify a dataset. No SQL
> assignment of itself changes the *state* of the dataset.
> The Prepare method ---
> is not confined to statements that specify datasets (SELECT
> statements). Prepare starts a conversation between client and
server that
> involves sending a statement of any kind to the server for
approval. If
> the server thinks the statement is OK, it sends back a message to
> client that includes information that your application needs to
have in
> order to permit its subsequent method calls to work.
> Updatable datasets (remember, they are formed from SELECT
> comprise several SQL statements. The properties InsertSQL,
> DeleteSQL and LockSQL are all SQL statements that we refer to
as "DML
> statements". DML is a mnemonic for Data Manipulation Language -
the subset
> of SQL that is capable of changing data.
> If a dataset is naturally updatable AND we indicate that we want it
to be,
> by setting RequestLive true, then the dataset constructs the
> xxxxSQL statement when it discovers it needs to. It uses the data
> characteristics of the SELECT query specification to work out what
> statement should be. If it doesn't already know what that
statement is, it
> will calculate it as part of its activity during the transition
> dssBrowse to whatever DML method has been called.
> So, if you call the dataset's INSERT method, and the dataset
> already have something in the InsertSQL property, it will try to
calculate one.
> If a Prepare on this InsertSQL statement is needed, an internal
call to
> Prepare *for that statement* will be done when the Post method is
> i.e. AFTER the user has entered her data.
> The IBO datasets provide for you to provide your own statements to
be used
> for inserts, updates, deletes and pessimistic locking. You
typically use
> this capability when you want a naturally non-updatable dataset to
> "live", or when you need your dataset's DML operation to perform a
> of statements instead of just one. In this case, you supply your
> xxxxSQL statement, typically a call to a stored procedure with
> parameters derived from the dataset's keys.
> Except in Inserts, the relationship between the dataset's keys and
> operation that is to be done by the xxxxSQL statement (your
supplied one,
> or the one that the dataset constructs) is crucial. That's why a
> needs correct KeyLinks in order for edits (updates), deletes and
locking to
> succeed.
> >If I write an SQL "insert into Mytable ...."
> >then 'prepare' does this set the dss State at prepare time.
> >Or in the case of a TIB_query with a select statment does
> >MyQuery.insert change it into an insert SQL statement ??
> It will help to understand that state changes in the dataset happen
as the
> result of other things that happen *within the dataset*. Preparing
> dataset does not change its state; but, by the same token, there
are some
> things that can't happen unless the statement is prepared; and
there are
> some state changes that can't happen while the statement in
question is
> unprepared.
> IBO takes care of the required preparing and unpreparing most of
> time. This is always true of the statements encapsulated in a
> descendant, even a TIB_StoredProc which doesn't return a dataset
> executed, not selected). Under some conditions, it is a good idea
to test
> the "raw" TIB_Statement descendant, TIB_DSQL (if not Prepared then
> IB 6.0 and IB 5.x have a bug which necessitates Unpreparing and
Preparing a
> stored procedure, whether in an IB_DSQL or an IB_StoredProc, each
> Execute is called. That is because the message returned to the
client from
> the server after execution contains an invalid structure that
prevents the
> next execution from getting new input values for the parameters.
The bug
> was fixed in Firebird and probably IB 6.5 and onward, since Borland
> all of Firebird's bug fixes across to their 6.5 codebase. If you
are using
> IB, you need to take care of this yourself, because the IBO
datasets - as
> well as the VCL ones - can't detect whether you are using a
> version that has this bug.
> >ANy clarification welcomed. I have read and re-read the GSG but
> >confused.
> There is a diagram in the GSG that models the cycle of dataset
> changes in response to the method calls. It is the same concept
that is
> implemented in the VCL, except that the native IBO datasets have
two extra
> states that support their capability for encapsulated searching.
> is not intended to be a Delphi beginner guide - it needs to be used
> conjunction with the Delphi help if you are not already familiar
with the
> VCL. It sounds as if you'd get some enlightenment by reading the
> help for the State property of datasets...
> cheers,
> Helen
Thanks very much Helen.
I am sitting here at 04:00 uk time meditating on your very full reply.
What I am trying to do is as follows:
I have a Local database B and a central database A.
I have assembled a lot of stuff in the local database B and want to
send it to A.
The records match exactly except that the database B has different
record numbering (primary keys) from A.
I have been doing everything with a stored procedure. But this
involved a lot of programming and the error messages are not eaasy to
handle SO in course of a rewrite I decided to try to do without a
stored proc. I have 4 tables to send records from in this way. All
tied together with foreign keys.
I tried using datapump object but this seems overkill for 1 record.
I have an open record on database B and I can assign the fields of
this to a Tib_dsql...but this requires a lot of tping of parameter
SO instead I have a TIB_Query and copy the fields from the query on B
into the fields of the query on B (For j = 0 to fieldcount-1 ...)

Then I do qryonA.insert ... but I presume this just sets things into
an insert state. Then qryonA.execute. This seems to work, but am I
doing a sensible thing. There are so many apparently different ways
of achieving an end in IBO and I never know which is best !!