What if one of your columns called a user defined function on every row returned?? Say this function resulted in a large load on the server, but was fine for datasets of a couple of dozen records? Now what if this table had millions of records in it?? I really wouldn't want a * query beating the crap out of my server.
I know what you meant. It is NOT supported by Linq.
You would have to use some very ugly Reflection code in a seperate method to build a new object from the supplied objects, then build your collection from there. No, I don't have an example because it's a very bad idea to do what your thinking about.
Just because you can do it in a database engine doesn't mean you can do it in Linq. Linq is not a database engine.
Nope. It should still be banned then. You should always know what's being returned. Relying on SELECT * is just being lazy - how long does it really take to explicitly select columns, especially given the number of code generators that abound.
I have seen many production systems where views are used to streamline access to tables and avoid direct access to tables. In these cases, a view is just a "wrapper" around a table. Imagine, if the underlying table structure changes (new column added or an existing column removed), then the view becomes invalid and has to be updated with the new structure. Doing a SELECT * in this situation will avoid this issue.
I know it is still bad, but there are already millions of systems that do this. Wherever I am asked to do a database upgrade or performance improvement, I am very cautious about views and don't touch them unless I'm sure of what I am doing.
Have you asked yourself how to paging in the DevExpress GridControl
No. Never wanted to do it. Why do you ask?
But if you want to, then you could always try looking for a search engine that might help. There must be one...oh! Here is one you might not have heard of: Google[^]
You can ask it questions, and it finds pages that could help, apparently. Why does nobody know about this? It could be useful!
Why the heck would you put 25,000 records (or more!) into a GridView? Do you expect your users to look at them? And perhaps work out which one of them they are actually interested in? Would you want to sit there and do that?
And if your users aren't going to look at all those, then why are you wasting time, memory and space loading this into a GridView?
Instead, look at where you are getting this data from, and transfer that directly into Excel - that way, it may well be quicker, more efficient and a lot less likely to run out of memory...
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
The coreadudio.dll working fine in visual studio 4.0 but I can't work with visual studio 3.5. My client is using visual studio 2008. so if there is any chance to do it in 2008 .. please give the solution..
if any download link that capable of working in 2008 ,please give me