|
So others can see it too
Kind of like Amazon
I loved/hated this and here's why...
Naturally expectation is lots of love 
|
|
|
|
|
|
Be USA, and his problem not mine
|
|
|
|
|
Which reminds me; not my problem 
It is weekend.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I haven't used it personally, but I have recommended Wix[^] to someone non-techy. This person found it easy enough to make something with it.
Jeremy Falcon
|
|
|
|
|
I was just coming to make the same recommendation (with the same evidence). Are you me?
TTFN - Kent
|
|
|
|
|
Yes, I am you. But you (I) knew that already since you're (I'm) the one typing this.
Jeremy Falcon
|
|
|
|
|
So, I'm trying to squeeze a bit more performance out of a LINQ query executed by EF. It's used pretty frequently and returns just a page of data at a time, complete with filtering and sorting support for various columns. This thing grabs data from 11 tables, basically a status summary row from a bunch of different operations on a single record.
I go look in the SQL Profiler at the query EF generates and find it's hitting the database about 25-ish times, once for the main page of data (pagable grid) and once for each record in the page to fill in a couple of pieces of data for those records that were accidentally not Included in the original query. OK, not problem, easy fix to remove those extra trips to the database. Quick'n'easy.
I also notice the main page query is a bit ... large. 544 lines of SQL with 19 LEFT OUTER JOINS! Wow. I knew EF generated some crappy SQL but this is ridiculous. The other 24-ish hits are small EF house keeping queries and filling in missing pieces of data from the original page query. Not big deal.
So, I put in a couple of missing Includes in the query code and test it out. Great! Down to five trips to the database instead of 25 and the grid page response is about four times faster than it was. Awsome!
Out of curiosity, I go look at the new SQL for the grid page query. It's now 977 lines of SQL with 35 LEFT OUTER JOINS!!  WOW!
Oh, it runs in less than 100 milliseconds.
|
|
|
|
|
To this day, I refuse to trust, or use, EF (or any other ORM) except for the most lightweight interactions.
The exception to that is my own ORM, because it's not a PoC.
Sadly, such attitude is rapidly making me obsolete in this industry, as I've actually never had to touch EF. Not that it isn't easy to learn at least the basics.
Marc
|
|
|
|
|
Marc Clifton wrote: To this day, I refuse to trust, or use, EF (or any other ORM)
The key is knowing exactly what's going on.
I love EF, but I'm also aware that it's a layer around your database.
You won't believe how many people forget that!
I've heard people say stuff like "we won't use a procedure because we have EF and we don't want to deal with the database directly!"
Well, guess what, you always deal with the database directly, because even if you're using an ORM it will directly influence the performance of your system!
I just prefer to write my queries strong typed in C# than in SQL, but I usually check whether EF makes a somewhat decent query
|
|
|
|
|
Sander Rossel wrote: I've heard people say stuff like "we won't use a procedure because we have EF and we don't want to deal with the database directly!"
Or do they really mean "don't know how to" rather than "don't want to."
Sin tack ear lol
Pressing the any key may be continuate
|
|
|
|
|
Probably
|
|
|
|
|
Sander Rossel wrote: I love EF, but I'm also aware that it's a layer around your database.
Where the database is your actual data-abstraction layer; the one that keeps you from having to track each item in a file you actually loop through, keeping it consistent and correct, and providing an abstract way of quering the data without the developer having to know any offsets or physical structure of the files.
Sander Rossel wrote: I've heard people say stuff like "we won't use a procedure because we have EF and we don't want to deal with the database directly!"
Which is a good enough excuse to pass around. The upside is that you no longer depend on a specific database-vendor, you just depend on EF.
Sander Rossel wrote: Well, guess what, you always deal with the database directly
No, I use the data-providers provided by the .NET framework. Which rely on a set of database-drivers, mostly MDAC. Those talk to the database directly 
Sander Rossel wrote: The key is knowing exactly what's going on.
The key! The whole key, and nothing but the key! So help me Codd!*
*) it's required
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: No, I use the data-providers provided by the .NET framework. Which rely on a set of database-drivers, mostly MDAC. Those talk to the database directly
Data-providers are for sissies and I don't need database drivers either! When I talk, the database just listens
|
|
|
|
|
I use EF all the time. I have used it for years. For the most part it works. I don't use it for ETL or big data loads etc. I will use stored procs instead.
|
|
|
|
|
Why not write your own sp and use that? Or am I missing the point?
|
|
|
|
|
I could do that, but this thing has been changing as the business keeps changing. It's easier to maintain this one in a migration and maintain strong typing than it is to keep changing the SQL. Also, the other people I work with are not so strong in SQL so it's easier for everyone involved to keep it in EF.
|
|
|
|
|
|
I'm in charge of the pinewood derby at my church. The finish line is electronic so I put the race results up on a large projector for everyone in the room to see. This all works great. I got to thinking it would be cool if I could put a camera (GoPro?) at the finish line down at ground level and feed that to the projector as well, maybe down in an unused corner. For you A/V aficionados that do this sort of thing regularly, is what I want to do possible, basically two inputs to the one projector? If so, what additional hardware/software would I need?
Thanks.
DC
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Check the projector. If it's digital - and I assume it is - it may well have picture-in-picture which might do it for you.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: ...it may well have picture-in-picture...
If it did, I'm not sure it would be of any benefit as the projector is mounted overhead some 20' up. It's input is a VGA cable over on the wall. Currently I plug the laptop's HDMI output to that VGA cable.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
If you have a couple months full time free, you should be able to coerce FFMPEG into doing PiP. 
Marc
|
|
|
|
|
You are a cruel, cruel man.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Quote:
You are a cruel, cruel man
I was wondering about that, but I was too polite to suggest!  Sorry Marc, I'll get my coat.....
Get me coffee and no one gets hurt!
|
|
|
|
|
It's already been done you know 😁
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
