Comments on: Views: VFP 9 Changed Behavior http://rickschummer.com/blog2/2007/10/views-vfp-9-changed-behavior/ Shedding some light on topics of software development, Visual FoxPro, saving our planet, paying it forward, and anything else I find important enough to share. Sun, 13 Jan 2019 18:50:16 +0000 hourly 1 http://wordpress.org/?v=3.0.3 By: nancyfolsom http://rickschummer.com/blog2/2007/10/views-vfp-9-changed-behavior/comment-page-1/#comment-798 nancyfolsom Mon, 02 Nov 2009 17:17:45 +0000 http://rickschummer.com/blog2/2007/10/views-vfp-9-changed-behavior/#comment-798 This behavior is what I would expect, and it is correct, IMO, given the problem of underlying, parameterized queries. The problem is extant with requerying local views that are based on local views. One has to loop through each underlying view and requerying in 8.0, also. <br /><br />I found this post while looking for a better, smarter solution to the NODATA, but it sounds like it is just as awkward as I'm finding. Or, rather, my data layer isn't designed entirely correctly. :-\ This behavior is what I would expect, and it is correct, IMO, given the problem of underlying, parameterized queries. The problem is extant with requerying local views that are based on local views. One has to loop through each underlying view and requerying in 8.0, also.

I found this post while looking for a better, smarter solution to the NODATA, but it sounds like it is just as awkward as I'm finding. Or, rather, my data layer isn't designed entirely correctly. :-\

]]> By: Rick Schummer http://rickschummer.com/blog2/2007/10/views-vfp-9-changed-behavior/comment-page-1/#comment-799 Rick Schummer Tue, 02 Oct 2007 16:11:06 +0000 http://rickschummer.com/blog2/2007/10/views-vfp-9-changed-behavior/#comment-799 Thanks for passing along this key information Sergey. I see the Fox Team perspective and understand the reasoning for change. I see definite advantage in the case when developers use the view-on-view technique.<br /><br />I just wish it had been documented. Not that I can recall every detail of the documentation, but at least I would have read this once. Thanks for passing along this key information Sergey. I see the Fox Team perspective and understand the reasoning for change. I see definite advantage in the case when developers use the view-on-view technique.

I just wish it had been documented. Not that I can recall every detail of the documentation, but at least I would have read this once.

]]> By: Sergey http://rickschummer.com/blog2/2007/10/views-vfp-9-changed-behavior/comment-page-1/#comment-800 Sergey Tue, 02 Oct 2007 15:52:00 +0000 http://rickschummer.com/blog2/2007/10/views-vfp-9-changed-behavior/#comment-800 Hi Rick,<br /><br />There was heated discussion about this change in behavior in VFP 9.0 on UT in thread #1101756. <br />I quote Aleksey Tsingauz's (VFP Team) explanation:<br /><br />NODATA clause is documented as the fastest method for determining the structure of a SQL view. It is also mentioned that, VFP achieves this goal by not retrieving data from the source. Therefore, avoiding waiting for the source to build a potentially large cursors.<br /><br />The old behavior, when VFP was still fetching data for referenced views, was contradicting documentation and the purpose of the NODATA clause. Besides the fetching issue, there was an inconsistent behavior in regard to parameterized views. When NODATA clause was used, one wasn't prompted for parameters for the view itself, but was prompted for parameters for referenced views (the side-effect of an attempt to fetch data). Therefore, the behavior was considered to be a bug and we've decided to make it consistent (i.e. do not prompt for parameters regardless whether they are used in the view itself or in referenced views) and aligned with documentation and the purpose of the NODATA clause. Hi Rick,

There was heated discussion about this change in behavior in VFP 9.0 on UT in thread #1101756.
I quote Aleksey Tsingauz’s (VFP Team) explanation:

NODATA clause is documented as the fastest method for determining the structure of a SQL view. It is also mentioned that, VFP achieves this goal by not retrieving data from the source. Therefore, avoiding waiting for the source to build a potentially large cursors.

The old behavior, when VFP was still fetching data for referenced views, was contradicting documentation and the purpose of the NODATA clause. Besides the fetching issue, there was an inconsistent behavior in regard to parameterized views. When NODATA clause was used, one wasn’t prompted for parameters for the view itself, but was prompted for parameters for referenced views (the side-effect of an attempt to fetch data). Therefore, the behavior was considered to be a bug and we’ve decided to make it consistent (i.e. do not prompt for parameters regardless whether they are used in the view itself or in referenced views) and aligned with documentation and the purpose of the NODATA clause.

]]>