xsharp.eu

Phil,

I won't go into all the details, but trust me I have played with many, and yes I did mention DataReader, but was more by example, since I do in general DataReader as stream and then oDataTable:Load(DataReader).

Have found that to be the quickest way of populating on slow server connections (still sit with sites that only have satellite connections) so for SQL retrieval and updates RAW sql is still the way to go with as little as possible network traffic.

We need to also consider, not everybody sit in the first world, but some of us do work in developing countries/continents. You might be from a technical perspective giving the most "advanced" solution to your clients, but I can guarantee you my "steam engine" will beat your supersonic solution every time if we have to compete for the same project.

You need to ensure that the solution is fit for the environment that the end user is working in.

LJ
PS: I don't bash you and the ideas, I do follow what is trending, but will jump onto the bandwagon only if it will benefit the scenarios that the solutions will run in.

Hi Jack,

Yes, horses for courses !

Nick too has to take speed and line quality / performance into account, as he serves large chunks of South America.

The reason that data readers etc. were done as they were is EXACTLY because of the connection speed etc., etc.. So minimal line data traffic.

These reasons are not applicable to those of us lucky enough to be in the first world (technically) and so we guys should be embracing the changes and modern approaches. For us the speed, or not, is far from a reason to stick with what we have always had.

After all, if there was not some sort of a REAL need then Microsoft wouldn't even invest a cent.

I was not bashing ;-0) Just getting frustrated at why so many guys wish to stick in the past, and ignore what was in place even 6 years past.

Good Luck and Best Wishes,
Phil.
P.S. I like steam trains!