Board index » delphi » Filter Problems - Does The Filter Property Required CachedUpdates True

Filter Problems - Does The Filter Property Required CachedUpdates True

The Following I have notice is the for the Filter Property to be used in
code or in the IDE by just set with the control - the only way I could get
the Filter to execpt a expresion was to set the CachedUpdates to True then
when I set the Active to true the filter would work this is in TTABLE. Maybe
their is another way in TTABLE if their is please explain. I need to keep my
question focus on TTABLE and Not TQUERY.  I would get the following error:

Capability not Supported Error:

What does Capability mean???

Please Explain in detail what does CachedUpdates mean and whats happening
inside the BDE going against SQL SERVER?

BY Setting the CachedUpdates to true the error does not happen but it causes
me to have run into some more trouble the following explains the problem in
detail below.

Quote

>  When I set the CachedUpdates To True the test for - While NOT(EOF)
> do - does not seem to work why is this the case. How do I get around this
> problem. This does to me seem like strange behaivor to me Do You have any
> ideas around this problem using TTABLE.

> > I Tried This Below And DID NOT GET THE ERROR:

> >              Active := False;
> >              ReadOnly := True;
> >              Filtered := False;
> >              Filter := 'Case_Numb =' + IntToStr(TempCaseNo);
> >              Filtered := True;

>                CachedUpdates := True;

> >              Active := True;                      // NO ERROR HERE

>      While NOT(EOF) do
>        begin

>                   // CODE HERE

>                   Application.ProcessMessages;

>            if NOT(KeepGoing) Then
>               Begin
>                   Last;   {Forces EOF to Become True}

>               End;

>          Next;

>        End;

>        PrevOldCaseNumber :=  OldCaseNumber;                   // NEVER
GETS
> HERE WHY

> When I hit the Next and their are no more records in the result set the
Next
> causes things to hang at least that is the why it seems in the debuger. I
> set a break point on the - PrevOldCaseNumber :=  OldCaseNumber - and the
> debuger never seems to get to that breakpoint the software seems to hang
at
> that point with the SQL cursor being displayed. So How do I in this case
> test the fact that I at the end of the result set return from SQL SERVER
> after using the filter statement - you said in the that I could just loop
> until EOF on that table when you described the filter properity in the
first
> place to me. But to me it seems like the test for EOF is a problem is this
> because the cachedupdate needs to be on for this filter statement to work.

   Note: The Next the first time loop back up and hits the While Not(EOF) Do
   so I assume that the result set does get walked through but how can I
tell that
   I have reached the end of the result set.

   By the way the QuotedStr() returned the following string which I do not

- Show quoted text -

Quote
> think we wanted in the first place 'Case_Numb = ' 1" which is not what I
> wanted so I used the first version which was without the QuotedStr() the
> following example below

> 'Case_Numb =' + IntToStr(TempCaseNo)

> Which returned the following string 'Case_Numb =  1' which is what I think
> is the string need for the filter to work.

> THANKS

 

Re:Filter Problems - Does The Filter Property Required CachedUpdates True


I have Tested the problem on both Delphi 4.0 and now 5.0 The problem in
Delphi 5.0 is even worse because when it hits the next in the first record
it stays their and does not go to the while so this behavior is different a
little bit. I ran the exact same code and the problem other then the above
is still a problem. So does anyone have a idea what I can do I realize that
I could look at third party solution and use oone of their filters. But I
want to exhast all posiable solution with out going to a third party
solution - If their is a solution within borland Delphi 4.0 or 5.0 I want to
use that. I no I might have to go and use the TQUERY but if their is a
solution anyone knows within TTABLE let me know. Is It Correct that for the
Filter to work I need to Turn CachedUpdates to true and if so how can walk
through the result set detet when I have reached the last record in the
result set. THANKS

Frank H. Shaw <fs...@runestones.com> wrote in message
news:8tvokd$dct2@bornews.borland.com...

Quote

> The Following I have notice is the for the Filter Property to be used in
> code or in the IDE by just set with the control - the only way I could get
> the Filter to execpt a expresion was to set the CachedUpdates to True then
> when I set the Active to true the filter would work this is in TTABLE.
Maybe
> their is another way in TTABLE if their is please explain. I need to keep
my
> question focus on TTABLE and Not TQUERY.  I would get the following error:

> Capability not Supported Error:

> What does Capability mean???

> Please Explain in detail what does CachedUpdates mean and whats happening
> inside the BDE going against SQL SERVER?

> BY Setting the CachedUpdates to true the error does not happen but it
causes
> me to have run into some more trouble the following explains the problem
in
> detail below.

> >  When I set the CachedUpdates To True the test for - While NOT(EOF)
> > do - does not seem to work why is this the case. How do I get around
this
> > problem. This does to me seem like strange behaivor to me Do You have
any
> > ideas around this problem using TTABLE.

> > > I Tried This Below And DID NOT GET THE ERROR:

> > >              Active := False;
> > >              ReadOnly := True;
> > >              Filtered := False;
> > >              Filter := 'Case_Numb =' + IntToStr(TempCaseNo);
> > >              Filtered := True;

> >                CachedUpdates := True;

> > >              Active := True;                      // NO ERROR HERE

> >      While NOT(EOF) do
> >        begin

> >                   // CODE HERE

> >                   Application.ProcessMessages;

> >            if NOT(KeepGoing) Then
> >               Begin
> >                   Last;   {Forces EOF to Become True}

> >               End;

> >          Next;

> >        End;

> >        PrevOldCaseNumber :=  OldCaseNumber;                   // NEVER
> GETS
> > HERE WHY

> > When I hit the Next and their are no more records in the result set the
> Next
> > causes things to hang at least that is the why it seems in the debuger.
I
> > set a break point on the - PrevOldCaseNumber :=  OldCaseNumber - and the
> > debuger never seems to get to that breakpoint the software seems to hang
> at
> > that point with the SQL cursor being displayed. So How do I in this case
> > test the fact that I at the end of the result set return from SQL SERVER
> > after using the filter statement - you said in the that I could just
loop
> > until EOF on that table when you described the filter properity in the
> first
> > place to me. But to me it seems like the test for EOF is a problem is
this
> > because the cachedupdate needs to be on for this filter statement to
work.

>    Note: The Next the first time loop back up and hits the While Not(EOF)
Do
>    so I assume that the result set does get walked through but how can I
> tell that
>    I have reached the end of the result set.

>    By the way the QuotedStr() returned the following string which I do not
> > think we wanted in the first place 'Case_Numb = ' 1" which is not what I
> > wanted so I used the first version which was without the QuotedStr() the
> > following example below

> > 'Case_Numb =' + IntToStr(TempCaseNo)

> > Which returned the following string 'Case_Numb =  1' which is what I
think
> > is the string need for the filter to work.

> > THANKS

Re:Filter Problems - Does The Filter Property Required CachedUpdates True


Quote
Frank H. Shaw wrote in message <8u23r9$8...@bornews.borland.com>...
>I have Tested the problem on both Delphi 4.0 and now 5.0 The problem in
>Delphi 5.0 is even worse because when it hits the next in the first record
>it stays their and does not go to the while so this behavior is different a
>little bit. I ran the exact same code and the problem other then the above
>is still a problem. So does anyone have a idea what I can do I realize that
>I could look at third party solution and use oone of their filters. But I
>want to exhast all posiable solution with out going to a third party
>solution - If their is a solution within borland Delphi 4.0 or 5.0 I want
to
>use that. I no I might have to go and use the TQUERY but if their is a
>solution anyone knows within TTABLE let me know. Is It Correct that for the
>Filter to work I need to Turn CachedUpdates to true and if so how can walk
>through the result set detet when I have reached the last record in the
>result set. THANKS

You should not have to turn CachedUpdates to true for the Filter to work,
they have nothing to do with each other. There is something else causing the
problem but at this point I'm afraid I'm out of ideas. I can set filters on
TTables on any sample database I have and they work just fine.

I have given you an alternative but you still refuse to even try it.

--
Wayne Niddery (WinWright Inc.)
RADBooks - http://members.home.net/wniddery/
I love deadlines. I like the whooshing sound they make as they pass by -
Douglas Adams

Re:Filter Problems - Does The Filter Property Required CachedUpdates True


Ok I used a third party solution I used InfoPower from Woll2woll software
they add a wwfilter properity to the end of their wwTTable control and I set
it they use TString unstead String and the CahedUpdates stays False the loop
seems to work just fine and EOF condition is caught at the end of result
set. I need to check with them to make shure their filter will work the same
as delphi should work if it was working so that only the records come back
from the server and not the entire table. I will see this as I bench mark
this against the exist data. THANKS

Wayne Niddery (TeamB) <winwri...@chaffhome.com> wrote in message
news:3a04e0a5_1@dnews...

Quote
> Frank H. Shaw wrote in message <8u23r9$8...@bornews.borland.com>...
> >I have Tested the problem on both Delphi 4.0 and now 5.0 The problem in
> >Delphi 5.0 is even worse because when it hits the next in the first
record
> >it stays their and does not go to the while so this behavior is different
a
> >little bit. I ran the exact same code and the problem other then the
above
> >is still a problem. So does anyone have a idea what I can do I realize
that
> >I could look at third party solution and use oone of their filters. But I
> >want to exhast all posiable solution with out going to a third party
> >solution - If their is a solution within borland Delphi 4.0 or 5.0 I want
> to
> >use that. I no I might have to go and use the TQUERY but if their is a
> >solution anyone knows within TTABLE let me know. Is It Correct that for
the
> >Filter to work I need to Turn CachedUpdates to true and if so how can
walk
> >through the result set detet when I have reached the last record in the
> >result set. THANKS

> You should not have to turn CachedUpdates to true for the Filter to work,
> they have nothing to do with each other. There is something else causing
the
> problem but at this point I'm afraid I'm out of ideas. I can set filters
on
> TTables on any sample database I have and they work just fine.

> I have given you an alternative but you still refuse to even try it.

> --
> Wayne Niddery (WinWright Inc.)
> RADBooks - http://members.home.net/wniddery/
> I love deadlines. I like the whooshing sound they make as they pass by -
> Douglas Adams

Re:Filter Problems - Does The Filter Property Required CachedUpdates True


If that is the case then please start with the TTABLE set all the properrtys
to the default settings and tell me each step that it takes to set it up to
work with a filter - I think the problem has something to do with going
against  a SQL SERVER database. I think or have a idea that their is a
problem or why would Woll2Woll would go about and set up its own new
properity that does not need a CachedUpdates to True.

Wayne Niddery (TeamB) <winwri...@chaffhome.com> wrote in message
news:3a04e0a5_1@dnews...

Quote
> Frank H. Shaw wrote in message <8u23r9$8...@bornews.borland.com>...
> >I have Tested the problem on both Delphi 4.0 and now 5.0 The problem in
> >Delphi 5.0 is even worse because when it hits the next in the first
record
> >it stays their and does not go to the while so this behavior is different
a
> >little bit. I ran the exact same code and the problem other then the
above
> >is still a problem. So does anyone have a idea what I can do I realize
that
> >I could look at third party solution and use oone of their filters. But I
> >want to exhast all posiable solution with out going to a third party
> >solution - If their is a solution within borland Delphi 4.0 or 5.0 I want
> to
> >use that. I no I might have to go and use the TQUERY but if their is a
> >solution anyone knows within TTABLE let me know. Is It Correct that for
the
> >Filter to work I need to Turn CachedUpdates to true and if so how can
walk
> >through the result set detet when I have reached the last record in the
> >result set. THANKS

> You should not have to turn CachedUpdates to true for the Filter to work,
> they have nothing to do with each other. There is something else causing
the
> problem but at this point I'm afraid I'm out of ideas. I can set filters
on
> TTables on any sample database I have and they work just fine.

> I have given you an alternative but you still refuse to even try it.

> --
> Wayne Niddery (WinWright Inc.)
> RADBooks - http://members.home.net/wniddery/
> I love deadlines. I like the whooshing sound they make as they pass by -
> Douglas Adams

Re:Filter Problems - Does The Filter Property Required CachedUpdates True


Why?  Wayne has already given you the solution,  use TQuerys.  What is this
obsession with using TTables?   You know, all the time you spent trying to
get TTables to work, you could have had the program done and wrote 10 more
following Wayne's advice.

Re:Filter Problems - Does The Filter Property Required CachedUpdates True


Quote
Frank H. Shaw wrote in message <8u5b3u$6...@bornews.borland.com>...
>If that is the case then please start with the TTABLE set all the
properrtys
>to the default settings and tell me each step that it takes to set it up to
>work with a filter -

All I do is drop a TTable on the form (or datamodule), hook it to a database
table, and in code I set the Filter and Filtered properties. If I have a
DBGrid attached then (at runtime) I immediately see only the correct records
according to the filter. I can change the filter in code and the DBGrid will
immedidately change also. This works against SQL Servers generally, I do not
have MSSQL to try it against but I'd be very surprised if it was any
different in this respect.

Sorry I can't help you any further than this. All I can suggest is try
creating another test application and see if this works there. If so then it
means there is something particular stopping it from working in your current
app.

--
Wayne Niddery (WinWright Inc.)
RADBooks - http://members.home.net/wniddery/
I love deadlines. I like the whooshing sound they make as they pass by -
Douglas Adams

Re:Filter Problems - Does The Filter Property Required CachedUpdates True


So how do I set the filtered properities - What are they and which ones need
to be set - That might be the problem. I do know that the Filtered Property
Needs To Be Set True. But the way it sounds their are other properitys that
can be set - Please explain I have not found any in the documentation that
tells about other properities. THANKS

Wayne Niddery (TeamB) <winwri...@chaffhome.com> wrote in message
news:3a06e876_2@dnews...

Quote
> Frank H. Shaw wrote in message <8u5b3u$6...@bornews.borland.com>...
> >If that is the case then please start with the TTABLE set all the
> properrtys
> >to the default settings and tell me each step that it takes to set it up
to
> >work with a filter -

> All I do is drop a TTable on the form (or datamodule), hook it to a
database
> table, and in code I set the Filter and Filtered properties. If I have a
> DBGrid attached then (at runtime) I immediately see only the correct
records
> according to the filter. I can change the filter in code and the DBGrid
will
> immedidately change also. This works against SQL Servers generally, I do
not
> have MSSQL to try it against but I'd be very surprised if it was any
> different in this respect.

> Sorry I can't help you any further than this. All I can suggest is try
> creating another test application and see if this works there. If so then
it
> means there is something particular stopping it from working in your
current
> app.

> --
> Wayne Niddery (WinWright Inc.)
> RADBooks - http://members.home.net/wniddery/
> I love deadlines. I like the whooshing sound they make as they pass by -
> Douglas Adams

Re:Filter Problems - Does The Filter Property Required CachedUpdates True


Yes Your are right but  - if it does not work in TTABLE then it should say
so - I need to understand what works and what does not using TTABLE - I have
a large application that I wrote that uses TTABLE so for me it is imporant
for me top understand these issue in with a real understanding - The
conversion program I wrote has brought a lot of new issue I need to address
to the serfice on how the BDE handles the things under the hood when going
against a SQL SEVER 6.5 database.  I also use in my application TQUERYS also
but because I started out with the main screens done with TTABLE it to hard
for me to change at this present time but over time I will be move to
TTQUERY - But presently I need to clearly understand and bench mark the
conversion application as I test the application with TTABLE and then
TQUERY.  So I am digging as much information about the inners of TTABLE and
testing by running bench marks and seeing for my self all the issues that
arise so the input I get from the information in the user group has
definetly help in my understand. THANKS

Quote
Kevin Frevert <kfrev...@midwayusa.com> wrote in message

news:3a06b474_1@dnews...
Quote
> Why?  Wayne has already given you the solution,  use TQuerys.  What is
this
> obsession with using TTables?   You know, all the time you spent trying to
> get TTables to work, you could have had the program done and wrote 10 more
> following Wayne's advice.

Re:Filter Problems - Does The Filter Property Required CachedUpdates True


Quote
Frank H. Shaw wrote in message <8u6u4m$n...@bornews.borland.com>...
>Yes Your are right but  - if it does not work in TTABLE then it should say
>so -

What should say so?  There are a number of conceptual differences between
C/S and desktop development.
Check this out (from Wayne):

=================================================
TTables vs. TQuerys

The whole reason there is both a TTable and a TQuery component is due to the
fact there table-oriented databases like Dbase, Paradox, or Access, and
there are set-oriented databases like Interbase, Oracle, and MSSQL. These
different types of database systems work and behave completely different
from one another and the same methods of access cannot be equally applied.

TTable is specifically designed to work best with table-oriented systems -
it is "native" to them. Using a TQuery against such databases is slower
because they do not understand SQL and so the BDE must interpret the SQL and
convert it to table calls for that database.

TQuery is specifically designed to work best with set-oriented databases
that understand SQL directly and were designed to work this way. Using a
TTable against such a system is slower because the BDE must convert the
table functions into SQL instructions to be sent off to the database.

Some of the things that TTables do that eat time and resources over a
network with an SQL system are:
- on Opening, always sends many queries to the database to get all the
metadata for all fields and indexes in the selected table in order to
provide you with a selection of these (only *Live* TQuerys do this).
- if you have large records with many fields, TTable will always select ALL
fields even if you only want one or two. This is especially bad if the table
contains blobs and you do not need them.
- Using Locate or FindKey or RecordCount forces all records to be fetched
because such searching / counting has to be done on the client side. This
can be eased by using a good filter (in the Filter property, not the
OnFilter event) to limit the records that need to be fetched (Filters are
turned into SQL where clauses by the BDE).
- if used in a grid, TTable must frequently execute multiple queries to fill
the grid whenever you change record positions.
- Tables prevent you from using the power of SQL when working against a real
SQL server - they only see physical tables (or views in SQL systems),
whereas you can write TQueries to slect any raltionships between and number
of tables and get only *exactly* the data you need.

With TQuerys, you still need to use them right to get the most out of them,
but the point is that you *can* use them right with regard to SQL databases.
- with the exception of extremely small "lookup" type tables (e.g. State
codes) *always* use where clauses to limit the number of records brought
back, if you do not then you are defeating the whole purpose of using them.
- unless you *really* need to every field in a table, always specify the
fields you actually need (e.g. "select cust_id, cust_name from...", not
"select * from..."). A tip here is to avoid editing records in a grid, use
grids only for selection. This allows you to only select the minimum fields
needed for selection, then use another query to select all fields for that
ONE selected record for editing purposes.
- Never use the Filter property or OnFilter event, or call RecordCount with
a TQuery, this forces the entire record set to be fetched. If you really
need the record count, use another query to get it so the server will do the
counting and send back the count itself instead of all the records.

--
Wayne Niddery (WinWright Inc.)
RADBooks - http://members.home.net/wniddery/
I love deadlines. I like the whooshing sound they make as they pass by -
Douglas Adams

-------------------------------------------------

Other Threads