If you're familiar with how joins work but are having problems figuring out how to use them in a particular query, it might be good to back up and look at the structure of the database you're working with. For instance, do you even have a good key to join on? A poor DB structure with a lack of normalization can make joins difficult or even impossible. If that's the problem, one way around it is to throw the data into temp tables with the correct structure you need for the joins and query against that. Speaking of which, in a addition to learning about SQL it's also a very good idea to learn the fundamentals of database design if you haven't already. Knowing about things like normalization, keys, and indexing really helps when writing SQL.

Uncategorised posts can refer to various topics that may include game updates or tips. In the context of the Bus Simulator Ultimate mod APK, these posts could provide players with insights on gameplay strategies, mod features like "no damage," or community discussions, helping to enhance their overall gaming experience and knowledge.

Yeah, never tell anyone about "plans".

Kent Sharkey wrote: I thought that was the purpose? And it now is the excuse. M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

But... does it have AI? M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

> they treat the customer like a $2 whore Oh man, I have got to use that line in a meeting some time. :laugh: Software Zen: delete this;

Richard Andrew x64 wrote: You must be a very valuable developer for them to keep you for 20 years. In this field, if they keep you for 10 years (or heck, even 5) you know you're invaluable, so they might as well keep you around for as long as they can pay you. Getting a developer familiar enough with a code base to change it without breaking it is costly. You stick with those employees who know their way around. After a while a junior developer might be cheaper in terms of compensation, but in terms of productivity, you should always stick with the old timers--you don't cut costs by getting rid of those people. That's an expensive lesson for those who need to learn it.

Checks? I remember those. There are no solutions, only trade-offs.    - Thomas Sowell A day can really slip by when you're deliberately avoiding what you're supposed to do.    - Calvin (Bill Watterson, Calvin & Hobbes)

Actually, if g(p) returns void, then this is definitely allowed. Makes generic programming easier, with less boilerplate, and faster compilation. Not sure what is supposed to happen if g(p) is something other than void - it should really be a syntax error.

My best practice doesn't fit either of your suggestions... If I am creating a new database layer (which I have numerous times) then the caller would never provide the SQL. If the business layer(s) need new database logic then the database layer should be modified to provide it. The caller provides the parameters that would be used in the call. Then within that database layer method it would decide how to process the parameters and SQL (provided by the method.) So it looks like the following. void DatabaseDoX(param1, param2,...) { // multiple variations possible std::string fullyFormedQuery = sprintf (SQL_X, param1, param2, ... ); There are quite a few variations on the above. For example consider the complication of a user initiated call where they might specify different 'query' terms (like data range, customer name, etc) But all still hide the SQL. Certainly there are design considerations for example your code might be coming from within the database layer (not a business call at all.) If so then I suspect that usage would actually vary depending on what the database layer was specifically doing in the code path.

... Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver

April Wine had some great songs, sad to hear. :( "the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle

New CDs added to the collection this year: (in no particular order) 0: Neal Morse Band - Innocence and Danger 1: Transantlantic - The Absolute Universe 2: Dream Theater - The Astonishing 3: Steven Wilson - The Harmony Codex 4: Porcupine Tree - Closure/Continuation I just had a conversation with my brother over Thanksgiving where he claimed that nobody is making good music anymore. :confused: My response was that you won't find 'good music' on mainstream channels. It's there, you just have to know where to look. "Go forth into the source" - Neal Morse "Hope is contagious"

Things get complicated when we are not able to understand them clearly. The other possible reason can be Overthinking, which exaggerates a simple situation and makes it appear worse. A person ends up imagining certain situations which in reality won't happen.