>>SP's are not just as vulnerable as SPT.

They CAN be. People who concatenate SQL or receive SQL for execution, are at risk. Those who execute SQL similar to that generated by a RV have avoided the risk.

>>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.

The point is about SQL Injection risk, not whether VFP was first to offer parameterized views. Not sure where that came from.

>>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.

No, the article would be about the risks of SQL Injection and how a VFP RV can be a useful tool to quickly and easily create safe, efficient SQL templates.

>>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.

??!! IME a database app generally has a data entry UI. Somewhere, somehow, humans need to be able to enter/edit data. Somewhere/somehow, data needs to get to and from the database to the screen. Voila, a database app. If the UI is achieved by a Winform, my contention is that things seem slow. Not sure how that could be converted into a lecture about tiered development or data coupling. If you are saying the slowness is caused by using control data binding, come out and say it.

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

In response to his contention about loading 5,000 rows from a database into a grid. I did not think I would need to belabor the point that we are talking about a database app there and have not suddenly started talking about music or graphic apps.

>>The PAINT.NET application has the following items when it is loaded... a list of mostly buttons presented
>>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.

I've yet to see a data entry screen for a database app that only uses buttons for data entry or display. What sort of data are you thinking of?!

>>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.

Of course one can create complex data entry forms in Winforms- has anybody said different? You say you do not notice the slowness. As I said, I'll remind you of that in due course. I am quite confident that improved winform performance will be a proud feature of 2005 even though you do not see a problem in 2003!