I can't find the answer to this MySQL question in the documentation:
If I execute "LOCK TABLES" through an ODBC connection, and a different thread already holds a lock on the specific table, does the calling thread block until the lock is acquired, or does the call simply fail and return immediately?
The difficult we do right away...
...the impossible takes slightly longer.
I need some help with an SQL query I’ve been asked to create.
Due to lack of communication, an update was done incorrectly and now needs to be fixed (surprise, surprise ). Each employee has 5 Ben_Codes and the start date for all Ben_Codes needs to be equal to the start date of Ben_Code 1. The dates are not constant so for each employee I need to read Ben_Code 1 record to retrieve start_date and then update Ben_Codes 2 thru 5 with that start_date.
To this point I have done very basic updates using SQL Query and would appreciate any guidance you can provide!!
So is this how the responder writes production code when it matters
Rubbish, fix the problem, fix it now and save the script, if it needs repeating then spend the time to make it elegant and efficient. Knowing that it is a kludge is more important than making a one off elegant.
Never underestimate the power of human stupidity
Perfect practice makes perfect. Do it the right way every time.
Nope. Not in the real world.
The real world is about money. Getting it perfect every time takes time and thus costs money. In the real world it isn't possible to get it perfect and most of the time it will not have any significant impact on actual required production functionality. Thus the extra cost is lost revenue which will never be regained.
This of course isn't the same as saying that one can write poor code all the time. But rather one must learn to recognize that ones time is in fact valuable and thus one must prioritize what one spends time on. And since, again in the real world, one can not spend an infinite amount of time on everything, one must make compromises.
And one might specifically look at this thread as an example and note that without knowing about the actual business of which this artifact is a part one will not have any idea about specifics such as size of the table, usage statistics, allowed maintenance, etc. And when one looks at all possible tables in all possible businesses, on average it won't matter.
I see too much bad SQL being written. It should be nipped in its bud.
Myself I see a lot of average code being written - it isn't specific to any language. Which is quite comforting since otherwise humans wouldn't be the ones writing it. If you are seeing a lot of poor SQL then maybe you need to start looking at a broader range of sources.
But of more import is that we are talking about a beginner who got this response from an expert* -- that's the big problem in my opinion. The beginner should be shown better code because he won't know any better otherwise. The poster, or other inexperienced developers who happen by, may think that the provided code is good for all situations.
* Anyone posting responses here assumes the role of expert with all the responsibilities thereof.
Michael Potter wrote:
increasing the code complexity
I don't think my solution is any more complex than the other solution.
Michael Potter wrote:
lower the lookups by a 5th
Correct me if I'm wrong (I could very well be), but my expectation of the first solution is n+1 lookups, whereas mine is 2 lookups. Granting that a modern database like SQL Server should work smarter than I would.
If you're going to teach a man to fish, do it right
The point here however is not how to fish.
Rather it is how to use a spinner when trolling for big mouth bass at dawn around slow moving water amoungst rocks. Which is something that someone might need to know. But not without the qualification. And it is not teaching them how to fish.
Thank you all for the responses. I was able to create the SQL I needed based on all your replies. I opt'd to follow example provided by PIEBALD as I am new to writing SQL and figure I should learn the more efficient methodology and when I am more versed in SQL I can do the quick and "dirty" when I have too.
Once again the help provided has been great and I really appreciate it!