Board index » delphi » I WOULD NEVER GO TO IB IF I KNEW....

I WOULD NEVER GO TO IB IF I KNEW....

So, I spend all day going to Ibcontrols and I must really say that NOTHING
works.

I were using Db controls on a IB5.5 database and all worked fine...

Now, I am on IB controls on a IB6 database and nothing works like before.

after half a day spent to have the script runnig under IB6 and my controls
to IB, I have so many problems that I'm happy to have saved all my datas on
the server....

The problem is that we decided to go opensource with IB6, so I must continue
going this way.

Here are my problems:

I have a TDbLookupCombobox. until now, I had 6 items shown when I clicked
the arrow. Now, since I changed, I only get ONE value at one time, instead
of a few values.

For what I have tested, after a request (insert, for example) my tIbSql
close their connection. So all my DB control don't work anymore.

I cannot insert datas anymore in the tables with this code:
              DataModule1.hFlightNumberTable.Insert;

DataModule1.hFlightNumberTable.FieldByName('FLIGHT_ID').AsInteger :=
NewFlightId;

I cannot use TIBTable, because everybody says not to use TIbTable...and I
don't know why....

I get crazy and would really tell to people trying to go to IB controls not
to do it.

 

Re:I WOULD NEVER GO TO IB IF I KNEW....


Quote
In article <3b61955e_1@dnews>, bedfo...@NOSPAMhotmail.com wrote...

Hi,

Quote
> So, I spend all day going to Ibcontrols and I must really say that NOTHING
> works.

IBX works just fine, with a few minor exceptions.

Quote
> I were using Db controls on a IB5.5 database and all worked fine...

> Now, I am on IB controls on a IB6 database and nothing works like before.

That is because you are using two completely different data access
methods.  The BDE is great for 'fileserver' databases (e.g. paradox),
but when it comes to SQL based RDBMS support is poor, so it just makes
them work like fileservers, by doing lots of client side caching and
'querying'.  IBX on the other hand is 'raw' access to the server, and
you have to use them differently than the BDE ones.  A different
approach, and a bit more code, but you get all the power and speed of
native access.

Quote
> I have a TDbLookupCombobox. until now, I had 6 items shown when I clicked
> the arrow. Now, since I changed, I only get ONE value at one time, instead
> of a few values.

Thats correct, when you open a 'query' only the first record is brought
back to the client, the next records are brought back as they are
requested.  If the lookup table is small, you could do a fetch all.

Quote
> For what I have tested, after a request (insert, for example) my tIbSql
> close their connection. So all my DB control don't work anymore.

Only if you commit the transaction.

Quote
> I cannot use TIBTable, because everybody says not to use TIbTable...and I
> don't know why....

Because TTables bring back all the fields and all the records for the
table to the client, and a lot of actions you can do with a TTable
causes the whole dataset to be re fetched.

Quote
> I get crazy and would really tell to people trying to go to IB controls not
> to do it.

If you try to use IBX as you do the BDE components, you will have loads
of problems, but if you use the IBX components as you do Interbase, you
will find they are a good set of components, and you will get great
performance.

Cheers

Phil

Re:I WOULD NEVER GO TO IB IF I KNEW....


Get the InterBase 6.0 Beta Documentation Set (10.04mb) from
http://www.borland.com/techpubs/interbase/

Developers Guide is for IBX.

Also please read my FAQ below. You'll find answers for most of your
questions there.

HTH,

-Jorge
-
IB/IBX F.A.Q.
http://ib.freeservers.com

Let your screen saver contribute to cancer research.
http://www.ud.com
A new way to help. Sponsored by Intel.

"Bob Bedford" <bedfo...@NOSPAMhotmail.com> escribi:

Quote
> So, I spend all day going to Ibcontrols and I must really say that NOTHING
> works.

Re:I WOULD NEVER GO TO IB IF I KNEW....


It took a week or so to jump to IBX.  Now that I know how it works and
understand well the Client/Server architecture, I know that IBX is really a
good thing, and it is very easy to control.

TIBTable is not a good choice because it is slower than IBDataSet.  Once
you've rigt-clicked the IBDataset and Set everything in the DataSet editor,
It behaves almost exactly as a IBTable, but is much faster.  Switching to
Client/Server architecture is not an easy task.  It sometimes need to work
hard.  But it worth it.  Jeff Overcash has done a very good job, providing
very fast and reliable components.

The only thing I can say to people is: Go with IBX ! but don't think it will
do all the job for you.  Drag n dropping IBX component and rename them is
not the only thing to do to go to a real Client/Server architecture.  Read
about it as much as possible before doing the jump.  Try the components on
simple projects before the big jump.

--
Frederic Gelinas
Programmeur-Analyste
Si Informatique
www.si.qc.ca

Re:I WOULD NEVER GO TO IB IF I KNEW....


I think a lot of people have this problem.  I think data bound controls are
the root of all evil.  (They are in league with Dr. Evil)

Local tables work great with scrolling cursors, but client/server arch. does
not.  How many people do we see using IBTables/IBDatasets and complaining
that they are slow and hard to use -- data bound controls are the cause of
this.  If they were forced to use client server the way its supposed to be
used we would not see this problem!

Please, Bob, dont think I'm flaming you personally, I'm saying we have seen
this problem many times and we should flame databound controls.

Soapbox.Free;

-Andy

Quote
"Bob Bedford" <bedfo...@NOSPAMhotmail.com> wrote in message

news:3b61955e_1@dnews...
Quote
> So, I spend all day going to Ibcontrols and I must really say that NOTHING
> works.

> I were using Db controls on a IB5.5 database and all worked fine...

> Now, I am on IB controls on a IB6 database and nothing works like before.

> after half a day spent to have the script runnig under IB6 and my controls
> to IB, I have so many problems that I'm happy to have saved all my datas
on
> the server....

> The problem is that we decided to go opensource with IB6, so I must
continue
> going this way.

> Here are my problems:

> I have a TDbLookupCombobox. until now, I had 6 items shown when I clicked
> the arrow. Now, since I changed, I only get ONE value at one time, instead
> of a few values.

> For what I have tested, after a request (insert, for example) my tIbSql
> close their connection. So all my DB control don't work anymore.

> I cannot insert datas anymore in the tables with this code:
>               DataModule1.hFlightNumberTable.Insert;

> DataModule1.hFlightNumberTable.FieldByName('FLIGHT_ID').AsInteger :=
> NewFlightId;

> I cannot use TIBTable, because everybody says not to use TIbTable...and I
> don't know why....

> I get crazy and would really tell to people trying to go to IB controls
not
> to do it.

Re:I WOULD NEVER GO TO IB IF I KNEW....


Hi!

Just give you the time to learn it correctly. It took me a week to well
understand  the basics. Now, I can't think of programming a DB application
without it... sincerely.

Ciao

VB

Re:I WOULD NEVER GO TO IB IF I KNEW....


Quote
Bob Bedford wrote:

> I have a TDbLookupCombobox. until now, I had 6 items shown when I clicked
> the arrow. Now, since I changed, I only get ONE value at one time, instead
> of a few values.

        That's a bug in TDBLookupComboBox.  It uses RecordCount internally, and
IBX is not the only component set which produces odd results with this
implementation.  The workarounds are either:

1.  Use a different DBLookupCombo.  The one from InfoPower works
properly, or:
2.  Fetch as many records as are in your dropDown when the lookup table
opens.  The easiest way to do this is with MoveBy.

Quote
> For what I have tested, after a request (insert, for example) my tIbSql
> close their connection.

        No, not after a request, after a Commit.

Quote
> I cannot insert datas anymore in the tables with this code:
>               DataModule1.hFlightNumberTable.Insert;

> DataModule1.hFlightNumberTable.FieldByName('FLIGHT_ID').AsInteger :=
> NewFlightId;

        You can, but it's more efficient to use a parameterized INSERT query to
do batch work.

Quote
> I cannot use TIBTable, because everybody says not to use TIbTable...and I
> don't know why....

        Because it's bad C/S design to fetch all columns and all rows.  This
and the point above are no different with IBX than with other InterBase
controls, including the BDE.

        -Craig

--
Craig Stuntz (TeamB)       Senior Developer, Vertex Systems Corp.
Delphi/InterBase weblog:   http://delphi.weblogs.com
Use Borland servers; posts via others are not seen by TeamB.
For more info, see http://www.borland.com/newsgroups/genl_faqs.html

Re:I WOULD NEVER GO TO IB IF I KNEW....


Quote
> That's a bug in TDBLookupComboBox.  It uses RecordCount internally, and
> IBX is not the only component set which produces odd results with this
> implementation.  The workarounds are...

IBO doesn't have a problem with this.

I wonder what Jeff needs to look into for a solution...

I think it could be the IsSequenced virtual override of TDataset.

Have him give that a look.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

Re:I WOULD NEVER GO TO IB IF I KNEW....


Quote
Jason Wharton wrote:

> > That's a bug in TDBLookupComboBox.  It uses RecordCount internally, and
> > IBX is not the only component set which produces odd results with this
> > implementation.  The workarounds are...

> IBO doesn't have a problem with this.

> I wonder what Jeff needs to look into for a solution...

There already will be a solution built into the new memory model that will come
with IB 6.5 later in the year.

Quote

> I think it could be the IsSequenced virtual override of TDataset.

I'll look at this too.

--
Jeff Overcash (TeamB)   I don't think there are any Russians
(Please do not email    And there ain't no Yanks
 me directly unless     Just corporate criminals
 asked.  Thank You)     Playing with tanks.  (Michael Been)

Re:I WOULD NEVER GO TO IB IF I KNEW....


Hi:

Quote
> There already will be a solution built into the new memory model that will come
> with IB 6.5 later in the year.

  And what exactly is IB 6.5 going to be??

Re:I WOULD NEVER GO TO IB IF I KNEW....


Quote
"Robert F. Tulloch" wrote:

> Hi:

> > There already will be a solution built into the new memory model that will come
> > with IB 6.5 later in the year.

>   And what exactly is IB 6.5 going to be??

By the end of the year according to what was said at BorCon.

--
Jeff Overcash (TeamB)   I don't think there are any Russians
(Please do not email    And there ain't no Yanks
 me directly unless     Just corporate criminals
 asked.  Thank You)     Playing with tanks.  (Michael Been)

Re:I WOULD NEVER GO TO IB IF I KNEW....


Quote
"Jason Wharton" <jwhar...@ibobjects.com> wrote in message

news:3b61f0e2$1_2@dnews...

Quote
> > That's a bug in TDBLookupComboBox.  It uses RecordCount internally, and
> > IBX is not the only component set which produces odd results with this
> > implementation.  The workarounds are...

> IBO doesn't have a problem with this.

> I wonder what Jeff needs to look into for a solution...

> I think it could be the IsSequenced virtual override of TDataset.

This sort of approach is what I used to get the TDBGrid to scroll properly
for a TIBDataset except that I added the code to the TDBGrid itself. That
way, it can work for any database type. I added a record count variable into
a modified DBGrids.pas and set it in my program. I eliminated the test for
IsSequenced and rely on the variable to contain the number of records, which
I set in my program using a select count(*) query. This provides the proper
operation of the vertical scrollbar. IMO, there should a flag for
non-recordcount oriented dataset components to allow it to do an additional
"select count(*)" operation when opening the dataset. When set, the dataset
performs the operation and sets IsSequenced to true. That way only the
datasets would need modifying, not the data-aware controls since they
already check for this.

I haven't looked at the IBO components or code, but is this anything like
what you implement Jason?

Woody

Re:I WOULD NEVER GO TO IB IF I KNEW....


It is similar to what I did in IBO. Here's the scoop.

In response to the TDBGrid control forcing a full record count depending on
the dataset's IsSequenced result I made a property called
RecordCountAccurate. What this property does is tell whether the RecordCount
property should return the accurate value (meaning use IBO's built-in
capability to parse together a SQL statement to determine the full record
count) or if it should just return the number of records in the buffer
(which is what IBX does).

So, the result of IsSequenced virtual override is influenced by the setting
of the introduced RecordCountAcurate property. By default I have it set to
true so that it emulates what TQuery and TTable would do for you. This makes
it so that RecordCount is accurate but tells the grid that it should not use
the count of records to provide better scrolling with the vertical
scrollbar. You get the 3 position thumb instead of a nice smooth thumb.

function TIBODataSet.IsSequenced: Boolean;
begin
  Result := false;
  if not Assigned( InternalDataset.OrderingParam ) then
    Result := not FRecordCountAccurate or AutoFetchAll;
end;

I have an additional introduced property called the ServerRecordCount (or
was it QueryRecordCount, I forget) who's purpose is to always deliver the
accurate record count.

The crux of the problem here is that under certain circumstances the TDBGrid
accesses the RecordCount property and this is potentially expensive in
client/server so this is all in an effort to continue to deliver accurate
behavior in code and avoid this control causing a performance issue.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

Quote
"Woody" <woody....@ih2000.net> wrote in message news:3b63233f_1@dnews...
> "Jason Wharton" <jwhar...@ibobjects.com> wrote in message
> news:3b61f0e2$1_2@dnews...
> > > That's a bug in TDBLookupComboBox.  It uses RecordCount internally,
and
> > > IBX is not the only component set which produces odd results with this
> > > implementation.  The workarounds are...

> > IBO doesn't have a problem with this.

> > I wonder what Jeff needs to look into for a solution...

> > I think it could be the IsSequenced virtual override of TDataset.

> This sort of approach is what I used to get the TDBGrid to scroll properly
> for a TIBDataset except that I added the code to the TDBGrid itself. That
> way, it can work for any database type. I added a record count variable
into
> a modified DBGrids.pas and set it in my program. I eliminated the test for
> IsSequenced and rely on the variable to contain the number of records,
which
> I set in my program using a select count(*) query. This provides the
proper
> operation of the vertical scrollbar. IMO, there should a flag for
> non-recordcount oriented dataset components to allow it to do an
additional
> "select count(*)" operation when opening the dataset. When set, the
dataset
> performs the operation and sets IsSequenced to true. That way only the
> datasets would need modifying, not the data-aware controls since they
> already check for this.

> I haven't looked at the IBO components or code, but is this anything like
> what you implement Jason?

> Woody

Re:I WOULD NEVER GO TO IB IF I KNEW....


Quote
"Andy Colson" <code...@cnip.net> wrote in message news:3b619c2c$1_1@dnews...

> Local tables work great with scrolling cursors, but client/server arch.
does
> not.  How many people do we see using IBTables/IBDatasets and complaining
> that they are slow and hard to use -- data bound controls are the cause of
> this.

This is really not true. Data-aware controls are just fine with
client/server applications. What is not fine is to try to use a
client/server database as though it were a flat file database such as
Paradox. *That* is what causes performance and other problems.

As long as one uses query components instead of table components then one
can control the data brought back from the server much better (e.g. control
the fields as well as the records). DBGrids are fine but should not be used
to edit records, only for display. Allowing editing on a dataset with a grid
attached causes a great deal of overhead. All other single field/row
controls (e.g. TDBEdit) are not a problem at all. This leaves the issue of
live queries which do cause some overhead - however if the live query is
limited to a single record select statement it isn't that bad. But this too
has an alternative - a non-live query with a an UpdateSQL component or,
better yet, clientdatasets.

--
Wayne Niddery (Logic Fundamentals, Inc.)
RADBooks: http://www.logicfundamentals.com/RADBooks/delphibooks.html
"Some see private enterprise as a predatory target to be shot, others as a
cow to be milked, but few are those who see it as a sturdy horse pulling the
wagon." - Winston Churchill

Re:I WOULD NEVER GO TO IB IF I KNEW....


Quote
In article <3b6347b3$1_2@dnews>, wnidd...@aci.on.ca wrote...

Hi,

Quote
> Data-aware controls are just fine with
> client/server applications. What is not fine is to try to use a
> client/server database as though it were a flat file database such as
> Paradox. *That* is what causes performance and other problems.

I totally agree with Wayne, but one thing I would like to add is be
using Data-ware controls, it is a lot easier to do things 'the wrong
way'.

By not using data-aware controls, although requiring slightly more code,
I find that it makes you think exactly how you are handling situations,
it is harder to do things 'the wrong way', and generally leads to better
use of transactions and other 'network traffic' issues.

Cheers

Phil

Go to page: [1] [2]

Other Threads