And here's a use case where SET FILTER can be quite useful in a production application. Let's say you have a form that displays account receivable transactions for a customer (invoices, payments, adjustments, etc.). You want to be able to display only open (i.e. unpaid) transactions or transactions related to a specific invoice. The primary query has returned all the rows I need to display for that customer. SET FILTER handles that quickly and simply without the overhead of running another query against the main database.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Gene Wirchenko Sent: Wednesday, May 15, 2019 2:55 PM To: profoxtech@leafe.com Subject: RE: Filtering Oddity
At 11:41 2019-05-15, Richard Kaye rkaye@invaluable.com wrote:
Gene and Woody's point is that XBASE tools are quite useful for us when developing/testing, not that they are necessarily preferable for production code.
Exactly.
One advantage that is particularly nice is that they are often short, simple, and fast. When I am chasing a bug or working on an idea, I prefer being able to get done what I want done fast. The protections that one might well want for an app are often not relevant.
[snip]
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
Richard, what you describe is a matter of personal taste. There is no overhaed in building a cursor with select * from myData where unpaid<>0 into cursor curUnpaid vs set fillter to unpaid <> 0 in myData. I, personaly, would prefer #1 in the enduser environment environment# 2 in my development environment - version(2)#0 vs version(2)=0. There is also no need to call a select() statement an overhead. Regards, Koen
Op do 16 mei 2019 om 00:23 schreef Richard Kaye rkaye@invaluable.com:
And here's a use case where SET FILTER can be quite useful in a production application. Let's say you have a form that displays account receivable transactions for a customer (invoices, payments, adjustments, etc.). You want to be able to display only open (i.e. unpaid) transactions or transactions related to a specific invoice. The primary query has returned all the rows I need to display for that customer. SET FILTER handles that quickly and simply without the overhead of running another query against the main database.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Gene Wirchenko Sent: Wednesday, May 15, 2019 2:55 PM To: profoxtech@leafe.com Subject: RE: Filtering Oddity
At 11:41 2019-05-15, Richard Kaye rkaye@invaluable.com wrote:
Gene and Woody's point is that XBASE tools are quite useful for us when developing/testing, not that they are necessarily preferable for production code.
Exactly. One advantage that is particularly nice is that they are oftenshort, simple, and fast. When I am chasing a bug or working on an idea, I prefer being able to get done what I want done fast. The protections that one might well want for an app are often not relevant.
[snip]
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
Depending on the select it might well just be filtering internally anyway, hence the 'nofilter' clause.
Alan, In this case select..into nofilter is according to me not the same as the english no filter, it means 'select again and disregard the previous select' Regards, Koen
Op do 16 mei 2019 om 10:49 schreef Alan Bourke alanpbourke@fastmail.fm:
Depending on the select it might well just be filtering internally anyway, hence the 'nofilter' clause.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
On Thu, 16 May 2019, at 6:26 AM, Koen Piller wrote:
Richard, what you describe is a matter of personal taste. There is no overhaed in building a cursor with select * from myData where unpaid<>0 into cursor curUnpaid vs set fillter to unpaid <> 0 in myData. I, personaly, would prefer #1 in the enduser environment environment# 2
in
my development environment - version(2)#0 vs version(2)=0. There is also no need to call a select() statement an overhead. Regards, Koen
Op do 16 mei 2019 om 00:23 schreef Richard Kaye rkaye@invaluable.com:
And here's a use case where SET FILTER can be quite useful in a
production
application. Let's say you have a form that displays account receivable transactions for a customer (invoices, payments, adjustments, etc.).
You
want to be able to display only open (i.e. unpaid) transactions or transactions related to a specific invoice. The primary query has
returned
all the rows I need to display for that customer. SET FILTER handles
that
quickly and simply without the overhead of running another query
against
the main database.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Gene Wirchenko Sent: Wednesday, May 15, 2019 2:55 PM To: profoxtech@leafe.com Subject: RE: Filtering Oddity
At 11:41 2019-05-15, Richard Kaye rkaye@invaluable.com wrote:
Gene and Woody's point is that XBASE tools are quite useful for us
when
developing/testing, not that they are necessarily preferable for production code.
Exactly. One advantage that is particularly nice is that they are oftenshort, simple, and fast. When I am chasing a bug or working on an
idea, I
prefer being able to get done what I want done fast. The protections
that
one might well want for an app are often not relevant.
[snip]
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
As Uncle Ted says, you have to test with your typical dataset to determine when a query has more overhead than using VFP's native functionality. Leaving aside the use of "select *", another matter of personal taste 😊, when your table has a relatively small number of rows and columns I'd agree. There's very little overhead to another call to the database. But with larger, wider datasets that may not be true. If I've selected 300 rows from a million row table, I'd be willing to be that SET FILTER on the resulting in memory cursor is more performant than going back to the database, particularly if my filtering queries are not as optimizable.
There are also other considerations to be taken into account such as how the cursor is being used. For example, grids are not real happy when you mess with the datasource.
The joy of VFP is the wide assortment of tools available. Using just SQL to solve every data related process is like using a screwdriver to hammer a nail. You can do it but there might be a better tool in the toolbox. 😊
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Koen Piller Sent: Thursday, May 16, 2019 1:26 AM To: profoxtech@leafe.com Subject: Re: Filtering Oddity
Richard, what you describe is a matter of personal taste. There is no overhaed in building a cursor with select * from myData where unpaid<>0 into cursor curUnpaid vs set fillter to unpaid <> 0 in myData. I, personaly, would prefer #1 in the enduser environment environment# 2 in my development environment - version(2)#0 vs version(2)=0. There is also no need to call a select() statement an overhead. Regards, Koen
Op do 16 mei 2019 om 00:23 schreef Richard Kaye rkaye@invaluable.com:
And here's a use case where SET FILTER can be quite useful in a production application. Let's say you have a form that displays account receivable transactions for a customer (invoices, payments, adjustments, etc.). You want to be able to display only open (i.e. unpaid) transactions or transactions related to a specific invoice. The primary query has returned all the rows I need to display for that customer. SET FILTER handles that quickly and simply without the overhead of running another query against the main database.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Gene Wirchenko Sent: Wednesday, May 15, 2019 2:55 PM To: profoxtech@leafe.com Subject: RE: Filtering Oddity
At 11:41 2019-05-15, Richard Kaye rkaye@invaluable.com wrote:
Gene and Woody's point is that XBASE tools are quite useful for us when developing/testing, not that they are necessarily preferable for production code.
Exactly. One advantage that is particularly nice is that they are oftenshort, simple, and fast. When I am chasing a bug or working on an idea, I prefer being able to get done what I want done fast. The protections that one might well want for an app are often not relevant.
[snip]
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
_______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/CACUu1SuZCHFmVGNj1gWXBN5y=f31pGCt4owKp3s4Mm... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Report [OT] Abuse: http://leafe.com/reportAbuse/CACUu1SuZCHFmVGNj1gWXBN5y=f31pGCt4owKp3s4MmP54f...
Hi Koen,
I respectfully disagree. In my case, I grabbed all of the Server data locally into a cursor, and then I use the SET FILTER on that to show the respective data when appropriate. This is better than repeat trips to the Server via the SQL SELECT. I'll take that bet every day of the week that ends in 'y' .  ;-)
On 5/16/2019 1:26 AM, Koen Piller wrote:
Richard, what you describe is a matter of personal taste. There is no overhaed in building a cursor with select * from myData where unpaid<>0 into cursor curUnpaid vs set fillter to unpaid <> 0 in myData. I, personaly, would prefer #1 in the enduser environment environment# 2 in my development environment - version(2)#0 vs version(2)=0. There is also no need to call a select() statement an overhead. Regards, Koen
Op do 16 mei 2019 om 00:23 schreef Richard Kaye rkaye@invaluable.com:
And here's a use case where SET FILTER can be quite useful in a production application. Let's say you have a form that displays account receivable transactions for a customer (invoices, payments, adjustments, etc.). You want to be able to display only open (i.e. unpaid) transactions or transactions related to a specific invoice. The primary query has returned all the rows I need to display for that customer. SET FILTER handles that quickly and simply without the overhead of running another query against the main database.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Gene Wirchenko Sent: Wednesday, May 15, 2019 2:55 PM To: profoxtech@leafe.com Subject: RE: Filtering Oddity
At 11:41 2019-05-15, Richard Kaye rkaye@invaluable.com wrote:
Gene and Woody's point is that XBASE tools are quite useful for us when developing/testing, not that they are necessarily preferable for production code.
Exactly. One advantage that is particularly nice is that they are oftenshort, simple, and fast. When I am chasing a bug or working on an idea, I prefer being able to get done what I want done fast. The protections that one might well want for an app are often not relevant.
[snip]
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
Richard, instead of grabbing all of your Data from the server and consequently filter to the data you require you could also consider to select just the subset of data you require in one go. That seems faster to me. Also how do you 'grab' the data from the server. Also I dont see why creating a subset of your equired data from your data is better than to set a filter. Anyhow this still seems to me a matter of taste, a matter of coding, as no one can ever see the difference in the endresult between a set of data with select..where or set filter to.. it is your preference and in case you are fine with it and you dont intend to do this in a enduser environment I would just do it the way you think is best for you.
Regards, Koen
Op do 16 mei 2019 om 22:36 schreef MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com>:
Hi Koen,
I respectfully disagree. In my case, I grabbed all of the Server data locally into a cursor, and then I use the SET FILTER on that to show the respective data when appropriate. This is better than repeat trips to the Server via the SQL SELECT. I'll take that bet every day of the week that ends in 'y' . ;-)
On 5/16/2019 1:26 AM, Koen Piller wrote:
Richard, what you describe is a matter of personal taste. There is no overhaed in building a cursor with select * from myData where unpaid<>0 into cursor curUnpaid vs set fillter to unpaid <> 0 in myData. I, personaly, would prefer #1 in the enduser environment environment# 2
in
my development environment - version(2)#0 vs version(2)=0. There is also no need to call a select() statement an overhead. Regards, Koen
Op do 16 mei 2019 om 00:23 schreef Richard Kaye rkaye@invaluable.com:
And here's a use case where SET FILTER can be quite useful in a
production
application. Let's say you have a form that displays account receivable transactions for a customer (invoices, payments, adjustments, etc.). You want to be able to display only open (i.e. unpaid) transactions or transactions related to a specific invoice. The primary query has
returned
all the rows I need to display for that customer. SET FILTER handles
that
quickly and simply without the overhead of running another query against the main database.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Gene Wirchenko Sent: Wednesday, May 15, 2019 2:55 PM To: profoxtech@leafe.com Subject: RE: Filtering Oddity
At 11:41 2019-05-15, Richard Kaye rkaye@invaluable.com wrote:
Gene and Woody's point is that XBASE tools are quite useful for us when developing/testing, not that they are necessarily preferable for production code.
Exactly. One advantage that is particularly nice is that they are oftenshort, simple, and fast. When I am chasing a bug or working on an
idea, I
prefer being able to get done what I want done fast. The protections
that
one might well want for an app are often not relevant.
[snip]
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
On Fri, 17 May 2019, at 12:25 PM, Koen Piller wrote:
Richard, instead of grabbing all of your Data from the server and consequently filter to the data you require you could also consider to select just the subset of data you require in one go.
Definitely this in a deployed application. Unless the table is fairly small.
Alan, In that case we are talking about a complete different situations. I was referring to a procedure to be applied in a multiuser app. In your case you are best off with coding you, yourselve like best. Regards, Koen
Op vr 17 mei 2019 om 13:39 schreef Alan Bourke alanpbourke@fastmail.fm:
On Fri, 17 May 2019, at 12:25 PM, Koen Piller wrote:
Richard, instead of grabbing all of your Data from the server and consequently filter to the data you require you could also consider to select just the subset of data you require in one go.
Definitely this in a deployed application. Unless the table is fairly small.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
On 5/15/2019 6:23 PM, Richard Kaye wrote:
And here's a use case where SET FILTER can be quite useful in a production application. Let's say you have a form that displays account receivable transactions for a customer (invoices, payments, adjustments, etc.). You want to be able to display only open (i.e. unpaid) transactions or transactions related to a specific invoice. The primary query has returned all the rows I need to display for that customer. SET FILTER handles that quickly and simply without the overhead of running another query against the main database.
--
rk
EXACTLY!!! That's been (part of) the beauty of FoxPro for years, something other programs didn't (and perhaps still don't) have.
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
-
Alan Bourke -
Koen Piller -
MB Software Solutions, LLC -
Richard Kaye