Take out database technology off .NET and you'll only miss ADO.NET.I don't understand this point. The database technology in .NET includes the data providers. Plus, take out ADO.NET and you take away the ability to do many things, such as generate reports in CR.NET in a distributed environment. This statement truly makes no sense.
It might not be a big issue, or it might be a big issue. SQL is a set based DML and not record based. If you're doing datamunging for example for the purpose of graphing where you often have to transform normalized data into non - normalized data and have to insert intermediate records for graphing (e.g. crystal reports) a record oriented approach is much easier.
And of course there is an issue of loading to much stuff onto the SQL server that really does not belong there in the first place. Writing numerous stored procedures on the server IMO often is a kludge o matic way of solving problems that should not exist in the first place. Please explain WHY this is kludgy. I want specifics. I've written queries to produce data in a weekly format for, say, a weekly sales bar chart. In a distributed environment, writing a stored proc on the server to prepare the result set (complete with series data) for the graph is a way to minimize client changes if/when the business rules for the graph change. I know this because I've done it.
However this is not the whole story Kevin, Aside from a note I found that when binding to a datagrid the recordset is going to be validated in its entirety (which I really cannot check), there is definately an issue when wanting to presenting something else than the first record in the grid. A general accepted method with large recordsets is using paging, but that has a side effect that the record set is run through from the beginning for each page change. So with large sets it is going through the top to the point you want to display. There have been reports that beeing a performance problem. Whether that is significant in general I leave up to you, but this definately is a architectual difference from the way VFP handles grids. Assuming we're talking about Winform datagrids...I can develop a grid where I derive from the standard textbox column class, and override the paint event to call a function that shows a dollar column in red if the value exceeds a certain amount (the equivalent of setdynamicforecolor in VFP). I can load the grid with 5,000 rows immediately. Navigation through the grid, to the naked eye, appears to be roughly the same as Fox.
You'd be surprised of how many facts are fabricated this way.Actually, no I wouldn't, as I've seen plenty of them.
One of my original questions...
Please provide a specific instance where someone converted an app identified as 'Tastrade' level complexity, and then concluded that it was easy to port other apps. ...note that this specific question has gone unanswered.
Seeking records on other fields, maybe in conbination with descending indexes, filters and SET NEAR on is not provided.Again, not totally accurate. You can execute rowfilters on a resultset, to either create an array of rows, or a view of a resultset based on the filter.
No, .NET requires them to be done differently... Yes, which isn't much different from what I said. The point is that many things can be done, just differently. There is far too much emphasis on literal, command vs command, function vs function comparisons between the two products. As others have pointed out, many developers coming from VB, Delphi, and other tools are able to pick up on .NET and build data-driven apps without difficulty. They're looking at a slighly bigger picture, and aren't getting bogged down in the fact that a particular function is missing and requires 10-20 lines or so to build a functional couterpart.
Well I do, I'm resisting to the mechanism of loading the SQL server with this kind of rubbish. In VFP you have a choice. Process it locally or on the SQL server. You can make a strategic decision here. In .NET you don't have much of a choice. I have yet to hear one valid technical argument why doing this type of work in a stored proc is 'rubbish'.
Anyways you responded to my list of facts. In so far you did not reject the list of facts. All you did marginalize the consequences of the facts. I've asked you to provide specifics to back some of your claims, and you have not. Simply because you made some points doesn't make them facts.
Kevin
