Board index » delphi » IBX TIBDataSet.QXXXX gone?

IBX TIBDataSet.QXXXX gone?

Hi:

I just downloaded the latest IBX for D5 Pro (i.e. No TClientDatasets) and
was not very happy to see that the access to the QInsert, QModify, etc have
been reduced to protected.

I have a great many non database aware components that control server based
procedures.  Buttons do things such as insert, update, etc .  eg:

procedure TFormBookCopies.BitBtnPostClick(Sender: TObject);
begin
  WITH DataModuleLibrary.IBDataSetBookCopies DO BEGIN
    QInsert.Params.ByName('BOOK_ID').AsInteger := BookID;
    .....etc.

Now, without QInsert as a protected property, how can I assign my stored
procedure parameters?  There is a Params propety, but I was never sure it
did anything but access the select statement.  I do not like using a
storedprocedure component as they are clunky and you need 4 to just do what
TIBDataset wrapped up into one component did.  I also do not use cached
updates (so as I understand it, I can not use OnUpdateRecord), nor do I like
update objects, because again everyting is handled on the server using
stored procedures.

Am I looking at doing a full re-write, promoting the properties myself back
to their published state or is there another alternative?

Thanks for your help

Kevin

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.314 / Virus Database: 175 - Release Date: 1/11/2002

 

Re:IBX TIBDataSet.QXXXX gone?


Quote
Kevin wrote:

> Hi:

> I just downloaded the latest IBX for D5 Pro (i.e. No TClientDatasets) and
> was not very happy to see that the access to the QInsert, QModify, etc have
> been reduced to protected.

I warned multiple times it would be moved back to protected over 18 months ago.

Quote
> I have a great many non database aware components that control server based
> procedures.  Buttons do things such as insert, update, etc .  eg:

> procedure TFormBookCopies.BitBtnPostClick(Sender: TObject);
> begin
>   WITH DataModuleLibrary.IBDataSetBookCopies DO BEGIN
>     QInsert.Params.ByName('BOOK_ID').AsInteger := BookID;
>     .....etc.

This is incorrect use and one of the main reasons it was put back to protected.
In the future QInsert will not even be a TIBSQL.

The proper way to do this is

  WITH DataModuleLibrary.IBDataSetBookCopies DO
  BEGIN
    Insert;
    FieldByName('BOOK_ID').AsInteger := BookID;
    ....
    Post;
  END;

Quote
> Now, without QInsert as a protected property, how can I assign my stored
> procedure parameters?  
> There is a Params propety, but I was never sure it
> did anything but access the select statement.  

When you post an Insert IBX moves the new field values into the simularly names
params in the InsertSQL automatically.

Quote
> I do not like using a
> storedprocedure component as they are clunky and you need 4 to just do what
> TIBDataset wrapped up into one component did.  I also do not use cached
> updates (so as I understand it, I can not use OnUpdateRecord), nor do I like
> update objects, because again everyting is handled on the server using
> stored procedures.

> Am I looking at doing a full re-write, promoting the properties myself back
> to their published state or is there another alternative?

> Thanks for your help

> Kevin

> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.314 / Virus Database: 175 - Release Date: 1/11/2002

--
Jeff Overcash (TeamB)
      (Please do not email me directly unless  asked. Thank You)
A human being should be able to change a diaper, plan an invasion, butcher
a hog, conn a ship, design a building, write a sonnet, balance accounts, build
a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act
alone, solve equations, analyze a new problem, pitch manure, program a computer,
cook a tasty meal, fight efficiently, die gallantly.  Specialization is for
insects.   (RAH)

Re:IBX TIBDataSet.QXXXX gone?


Quote
> I warned multiple times it would be moved back to protected over 18 months

ago.

Sorrry, but I do not regularly check this newgroup, do not download all
articles, and I only read about 1% of messages with titles that peak my
interest.  I only noted there was an update from the July 2000 posted
download (18 months old) at Borland's Interbase web page by doing a search
for another related topic.

Quote
> This is incorrect use and one of the main reasons it was put back to
protected.
> In the future QInsert will not even be a TIBSQL.

But you then still left it protected?  Why allow component developers to
shoot themselves in the not too distant future foot?  Not a critique, just
curious as it seems counter productive.

Quote
> This is incorrect use and one of the main reasons it was put back to
protected.
> In the future QInsert will not even be a TIBSQL.

QInsert references a TIBSQL component, why not use what it there?  If you
wanted to discourage use because you were changing from TIBSQL that is one
thing, but I do not see why that makes it "incorrect use".  I might buy
"less efficient".

Quote
>  WITH DataModuleLibrary.IBDataSetBookCopies DO
>  BEGIN
>    Insert;
>    FieldByName('BOOK_ID').AsInteger := BookID;
>    ....
>   Post;
>  END;
> When you post an Insert IBX moves the new field values into the simularly
names
> params in the InsertSQL automatically.

Makes sense but that was never, without any clue that I could see with any
clarity, given in the IBX online help.  I assume that that works the same
for Edit (i.e. Modify)?  What about Delete?

Thanks, for the update and help.

Kevin

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.314 / Virus Database: 175 - Release Date: 1/11/2002

Re:IBX TIBDataSet.QXXXX gone?


Quote
> The proper way to do this is

>   WITH DataModuleLibrary.IBDataSetBookCopies DO
>   BEGIN
>     Insert;
>     FieldByName('BOOK_ID').AsInteger := BookID;
>     ....
>     Post;
>   END;

Actually, unless I am dumb as toast, that does not relate at all to what I
posted.  As I said in my original post, I have procedures on the server and
nondata aware controls doing the inserts, updates and deletes, so I have an
SQL like EXECUTE Insert_Book :BOOK_ID, :COPY_LOCATION.  There are no
"Fields" only Params.  FieldByname fails.

Quote
> When you post an Insert IBX moves the new field values into the simularly
names
> params in the InsertSQL automatically.

Re-reading this it seems that IBX moves the Params AFTER the post?  If this
is corret, that is useless for me as I need access to the params for the
Modify, Insert and Delete BEFORE the post.  If I am not reading this right,
then it does not work as I just tried it and the Params are stuck on what is
in the Select statement after the Insert and before the Post.

Needing help  here.

Kevin

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.314 / Virus Database: 175 - Release Date: 1/12/2002

Re:IBX TIBDataSet.QXXXX gone?


Quote
"Kevin" <ess.m...@adlibecostats.com> wrote in message

news:3c5111ed_2@dnews...

Quote
> Actually, unless I am dumb as toast, that does not relate at all to what I
> posted.  As I said in my original post, I have procedures on the server
and
> nondata aware controls doing the inserts, updates and deletes, so I have
an
> SQL like EXECUTE Insert_Book :BOOK_ID, :COPY_LOCATION.  There are no
> "Fields" only Params.  FieldByname fails.

The point is, you're trying to use TIBDataset for something it was not meant
for. TIBDataset is a TDataset descendant and was meant to be used in
place of eg. TTable, TQuery and such.

For your needs you should use either TIBSQL or TIBStoredProc. If the
idea that you now need three components on your data module where there
used to be one is intolerable, you might consider deriving your own
component having QInsert, QModify, QDelete : TIBSQL public or
published properties.

--ilkka hyv?rinen

Re:IBX TIBDataSet.QXXXX gone?


In article <3c512b11_2@dnews>, "Ilkka Hyv?rinen" <ilkka dot hyvarinen at
fulcrum dot fi> says...

Quote

> The point is, you're trying to use TIBDataset for something it was not meant
> for. TIBDataset is a TDataset descendant and was meant to be used in
> place of eg. TTable, TQuery and such.

        What he's doing will work fine if he uses dataset methods (Edit,
Post, etc.) instead of trying to deal with the TIBSQLs individually.  
Separate IBSQL components will also work.  He can take his pick of
techniques.

Quote
> For your needs you should use either TIBSQL or TIBStoredProc. If the
> idea that you now need three components on your data module where there
> used to be one is intolerable, you might consider deriving your own
> component having QInsert, QModify, QDelete : TIBSQL public or
> published properties.

        Don't do this.  It *will* break in the future.

        -Craig

--
 Craig Stuntz (TeamB) Vertex Systems Corp. Columbus, OH
     Delphi/InterBase WebLog: http://delphi.weblogs.com
     InterBase PLANalyzer (Free IB optimization tool):
          http://delphi.weblogs.com/IBPLANalyzer

Re:IBX TIBDataSet.QXXXX gone?


Quote
Kevin wrote:

> But you then still left it protected?  Why allow component developers to
> shoot themselves in the not too distant future foot?  Not a critique, just
> curious as it seems counter productive.

It was left protected so people who were using it could gracefully start pulling
back from using it.  In D7 where the internal implementation will be totally
changed to allow for scripting of update/insert/delete statements it will be
pulled fully back to private where it should have been in D5.  I did not control
its initial shipping of being public so I pulled it back in stages.

Quote
> > This is incorrect use and one of the main reasons it was put back to
> protected.
> > In the future QInsert will not even be a TIBSQL.

> QInsert references a TIBSQL component, why not use what it there?  

Because that is the internal implementation of how IBX takes changes to the
result set and propagates them to the DB.  As with any internal implementation
in a OOP framework, the exacts of that implementation may in the future be
changed (and with D7 it will be changed) which is why the actual implementation
details should never be made public.  I didn't make it public.

Quote
> If you
> wanted to discourage use because you were changing from TIBSQL that is one
> thing, but I do not see why that makes it "incorrect use".  

It is incorrect because you are causing the local result set to get out of sync
with the DB by not going through the proper method of updating result sets in
TDataset descendants.  The way you are using TIBDataset is clearly not the way
TDAtaset descendants were designed to be used.

Quote
> I might buy
> "less efficient".

No wrong.  I've had enough people have problems doing what you are doing that I
pulled it back earlier than I was planning.

Quote

> >  WITH DataModuleLibrary.IBDataSetBookCopies DO
> >  BEGIN
> >    Insert;
> >    FieldByName('BOOK_ID').AsInteger := BookID;
> >    ....
> >   Post;
> >  END;
> > When you post an Insert IBX moves the new field values into the simularly
> names
> > params in the InsertSQL automatically.

> Makes sense but that was never, without any clue that I could see with any
> clarity, given in the IBX online help.  I assume that that works the same
> for Edit (i.e. Modify)?  What about Delete?

Yes.  You never need to touch the params.  The params are filled from the
current record being inserted/modified/deleted.

Quote

> Thanks, for the update and help.

> Kevin

> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.314 / Virus Database: 175 - Release Date: 1/11/2002

--
Jeff Overcash (TeamB)
      (Please do not email me directly unless  asked. Thank You)
A human being should be able to change a diaper, plan an invasion, butcher
a hog, conn a ship, design a building, write a sonnet, balance accounts, build
a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act
alone, solve equations, analyze a new problem, pitch manure, program a computer,
cook a tasty meal, fight efficiently, die gallantly.  Specialization is for
insects.   (RAH)

Re:IBX TIBDataSet.QXXXX gone?


Quote
"Ilkka Hyv?rinen" wrote:

> If the
> idea that you now need three components on your data module where there
> used to be one is intolerable, you might consider deriving your own
> component having QInsert, QModify, QDelete : TIBSQL public or
> published properties.

Don't.  Future plans are to allow scripted Insert/Update/Modify statements.
This means the QXxxxx will not be TIBSQLs in the future (more than likely they
will become TLists of TIBSQLs, one entry for each needed SQL statement, but this
has not been finalized yet).

Quote
> --ilkka hyv?rinen

--
Jeff Overcash (TeamB)
      (Please do not email me directly unless  asked. Thank You)
A human being should be able to change a diaper, plan an invasion, butcher
a hog, conn a ship, design a building, write a sonnet, balance accounts, build
a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act
alone, solve equations, analyze a new problem, pitch manure, program a computer,
cook a tasty meal, fight efficiently, die gallantly.  Specialization is for
insects.   (RAH)

Re:IBX TIBDataSet.QXXXX gone?


Quote
Kevin wrote:

> > The proper way to do this is

> >   WITH DataModuleLibrary.IBDataSetBookCopies DO
> >   BEGIN
> >     Insert;
> >     FieldByName('BOOK_ID').AsInteger := BookID;
> >     ....
> >     Post;
> >   END;

> Actually, unless I am dumb as toast, that does not relate at all to what I
> posted.  As I said in my original post, I have procedures on the server and
> nondata aware controls doing the inserts, updates and deletes, so I have an
> SQL like EXECUTE Insert_Book :BOOK_ID, :COPY_LOCATION.  There are no
> "Fields" only Params.  FieldByname fails.

But you should have a SelectSQL that pulls back a result set.  If not, then you
should be using IBSQLs.  The whole purpose of the TDataset descendants to to
work on result sets from server, not to execute individual statements.  You work
on the Result set and IBX takes the changes to the Result Set and propagates
them to the Database.  The QXxxx stuff are the current internal implementation
on how that is performed.

Quote
> > When you post an Insert IBX moves the new field values into the simularly
> names
> > params in the InsertSQL automatically.

> Re-reading this it seems that IBX moves the Params AFTER the post?  

All the QXxxx methods are the internal implementation on how your changes to the
local result set get updated to the Server.  When you post a change to the local
result set IBX then takes those field values and assigns them to the appropriate
params of the appropriate SQL you supplied (in the case of an Insert ... Post it
is the InsertSQL) and executes that SQL to update the Database.

Quote
> If this
> is corret, that is useless for me as I need access to the params for the
> Modify, Insert and Delete BEFORE the post.  

No you don't.  You haven't given any reason why you would.

Quote
> If I am not reading this right,
> then it does not work as I just tried it and the Params are stuck on what is
> in the Select statement after the Insert and before the Post.

> Needing help  here.

Please ask in the interbaseexpress group if you need more help.

Quote

> Kevin

> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.314 / Virus Database: 175 - Release Date: 1/12/2002

--
Jeff Overcash (TeamB)
      (Please do not email me directly unless  asked. Thank You)
A human being should be able to change a diaper, plan an invasion, butcher
a hog, conn a ship, design a building, write a sonnet, balance accounts, build
a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act
alone, solve equations, analyze a new problem, pitch manure, program a computer,
cook a tasty meal, fight efficiently, die gallantly.  Specialization is for
insects.   (RAH)

Re:IBX TIBDataSet.QXXXX gone?


"Jeff Overcash (TeamB)" <jeffoverc...@mindspring.com> wrote in message
news:3C5186EE.B57152E9@mindspring.com...

Quote

> "Ilkka Hyv?rinen" wrote:

> > used to be one is intolerable, you might consider deriving your own
> > component having QInsert, QModify, QDelete : TIBSQL public or
> > published properties.

> Don't.  Future plans are to allow scripted Insert/Update/Modify
statements.
> This means the QXxxxx will not be TIBSQLs in the future (more than likely
they
> will become TLists of TIBSQLs, one entry for each needed SQL statement,
but this
> has not been finalized yet).

Hmm, I wasn't actually thinking about deriving from TIBDataset or anywhere
near there, more like from TComponent (suppose I should have said "create
from scratch" or something :-). What I had in mind was a sort of container
component for a couple of TIBSqls. No, I don't think that's actually a
sensible thing to do.

--ilkka hyv?rinen

- Show quoted text -

Quote
> --
> Jeff Overcash (TeamB)

Re:IBX TIBDataSet.QXXXX gone?


Quote
> Future plans are to allow scripted Insert/Update/Modify statements.

Sounds very cool, btw. Thanks for mentioning this, waiting with
anticipation...

--ilkka hyv?rinen

Other Threads