- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Wait, doesn't this mean that a badly timed restart of the system user-side could result in part of/the entire config getting deleted? Or am I misunderstanding the order of operations here?
Admin
It does read like a race condition, but that isn't mentioned and you would have thought it would be a screamingly obvious PITA if, indeed, it was happening.
Maybe that menu_cfg is in user-specific space and this is a cack-handed attempt at caching the conversion "configuration options" into an actual UI.
Whatever, inefficient and daft though it is I can't see why it causes such an extreme bottle neck for 400 rows and 16MB unless the network is really crap, or the database/server has "issues". I suppose if that's an example of the code quality it's a good guess there's plenty of other crap in there.
Admin
Presumably there's a transaction in there, somewhere? But given this site, should we assume that? Probably not.
Admin
Hm, let's say... a judicial use of a lack of indices?
Admin
It takes 30 seconds to perform an operation on 400 rows. Does that mean to do anything affecting 40,000 rows, it'll spin for almost an hour? Don't add any new menu items!!! Use buttons instead.
Admin
Admin
When I got to my last job, the idiot IPCs (inexplicably paid consultants) were trying to convince the boss that more memory had to be added to the db server, because we'd occasionally experience slowdowns in our main application. This application was very old, and poorly written even then.
I pointed out we had ~50 users. There's no way on earth that SQL Server can't handle the load we're putting on it. Did a little poking around, discovered that the main search function returned every row which qualified (and then displayed only one page of those results). As a bonus, the sproc underneath it all was vulnerable to injection attacks.
Explained all this to the boss, added a "new search" functionality (so we could before & after test--of course nobody had requirements) using EF/linq's built-in paging with take & skip. Got that tested out, released it--surprise, no more timeouts.
IPCs complained that EF & linq was "too hard", because "they're database guys."
A couple of humorous follow-ups.:
When we decided new search was good, we took away the old search from the menu, and renamed "new search" to just "search". in other words, went from two search menu options to one. Users froze up--"where's the new search, that was great". "Did you try to click the only search option now available?"
Somewhat later, I had SQL Profiler running, trying to figure out how a 3rd party tool queried the database. One of the IPCs, (remember, self-proclaimed "database guy"), wandered by and asked me what that tool was. Sigh.
Admin
There are only three hard things in programming: naming, caching and idiots.
Admin
You forgot "the feeling of you desk hitting your forehead" from that list.
Admin
TRWTF is why there was no syntax error on DELETE * FROM MENU_CFG;
Most people use DELETE FROM MENU_CFG; or TRUNCATE TABLE MENU_CFG;