Rod,

>> I think my contention was that is you use stored procs you wont have these problems (unless you do dynamic stuff in the procs themselves)

>>SPs can be just as vulnerable to injection as SPT. A RV never is. Those who have decided RVs are no >>good would do well to use them to create safe SQL templates for whatever mechanism they have >>decided is better.

SP's are not just as vulnerable as SPT. You will have problems in your SPT's if you use things like the EXEC command in SQL Server. You must do this on deliberatly. The mechanisms for calling stored procs ARE the same as those in RV's. The parameters are passed in exactly the same as you showed me in your RV example where it use SQLPREPARE (If I recall).


>>The injection article idea was not mine, and you are correct, I did not offer to write one. I must say I I >>had hoped that some of those who were planning articles to educate us re injection might have >>proceeded regardless. Instead it seems that the fact that the dreaded RV has addressed such >>a "modern" concern for almost a decade, means it is not so important after all. I disagree. I'd warrant >>there are lots of developers out there who believe they are safe and secure if they write SPs with >>specific access rights.

You act like parameterized views is a new concept. Actually if I recall... MS-ACCESS had this ability in 1992. So yes lots of developers have used the same concept much longer than VFPers.

>>I might consider writing an article showing users of other tools how to use VFP RVs to create safe SQL >>hat can be used in SPT or SP. Would you publish that?
So the article would be about VFP for other NON-VFP developers ? Probably not. Maybe next time we do a VFP focus issue I'll consider it.


>>As for WinForms performance.... you didnt mention that it had to be in the context of a database application.

>>What, you thought people would come to the VFP forum and complain about graphics apps? Of course >>people are comparing performance of database apps in this forum.

What does UI have to do with a database ? Multi-tier/layer development has been a generally accepted practice for some time now.... So you are stating that your UI is coupled to your data ? Come on now. You are trying to change the argument to serve your purpose.

Actually you didnt ask kevin about performance of .NET in a database context. You asked about WinForms performance in general.

>Whether it is a database application or a graphics package... They all contain listboxes, textboxes, buttons, labels, etc.... Is this not the case ?
>>Yes. But detailed entry Winforms still load sluggishly. Fast graphic applications, games and other non->>database apps do not change this.

The PAINT.NET application has the following items when it is loaded

1 toolbbox with 15 buttons,
A toolbar with 22 buttons, 3 labels, 4 drop downs
A color wheel toolbar with a color wheel, dropdown and a button
A layer dialog with half a dozen buttons,
A status bar,
A history dialog with 5 buttons
And the graphics area where you draw.

So wouldn't this screen be just as complex as any data entry form. You and I know that the database aspect of this is not relevant to the issue we are discussing.

If your opinion is that Winforms loads data entry screens slowly then so be it. It is my contention that it is not as slow as you claim. My experience shows me that you can create complex data bound data entry screens with WinForms.

Having fun as always,
Rodman