Are you kidding? This so-called "paper" was "co-written" by some Army chemists. If anything, it PROVES the conspiracy theories!

*adds yet another layer of tinfoil to an already heavy hat*

Check out the snapstream firefly . It's RF (not bluetooth), but if avoiding line of sight is your objective, then it will fit the bill. Works quite well with MythTV, and I've messed about with it on Windows (but not MCE) as well. My one complaint (and a fundamental one that I should have considered first) is that I can't control my tv with it. Next time, I'll get a single, converged remote.

I guess it's sort of nice that they can stick this nose cone on different rockets, but as far as American innovation goes...yawn.

Absolutely. Excellent suggestion to check out chapter 1 for free.

I'm an avid Tom Kyte reader, and I probably should have attributed my post as a paraphrase of that chapter. I sidestepped it simply because Oracle was not on the list of technologies the OP is interested in. I sincerely hope there are analogous books for other RDBMS's. That book sits on my desk, yet gathers very little dust.

I disagree completely. The "best" method varies widely, because it is specific to the RDBMS you're using.

OP says he understands how databases work, but it seems to be limited to how to put data in & get data out. A database is (or can be) more than a bit bucket. If it's taking too long to fetch records from a 10 million record table, there are some serious performance issues here. It could be any combination of bad data modeling, improper indexing, underpowered hardware, poorly configured concurrency/consistency controls, inefficient I/O subsystem, OLTP workload on a system configured for OLAP etc...

Understanding concepts like transactions, locking mechanisms, disaster recovery, table structure (heap vs clustered), index structure, temp tables, stored procedures/packages/functions, data types, etc. is important, but it's equally important to understand how your chosen RDBMS implements these so that you can fully exploit them. Armed with this knowledge and the needs of your business, you'll be able to refactor your data and/or applications appropriately

I think you can get at the concepts through practice - particularly since you're working with more than 1 RDBMS, but "getting" databases in general won't get you what you're looking for. Depending on the urgency here, you may find yourself hiring a gun to help sort out your situation, as the amount of research & testing required to get the knowledge you need to do this may not be practicable for an IT Director.

I hope this helps!

Seriously? I think it's brilliant marketing. Who wouldn't want to throw a WORM into their card reader?

I'll have 2, thank you.

This functionality you propose is available today, although not required (at least in Oracle where I'm familiar). Look into bind variables. in fact, let me google it for anybody reading this who wants to know how to prevent sql injection. http://www.lmgtfy.com/?q=bind+variables The positive side effect (again in Oracle) is that use of bind variables reduces the CPU cost of parsing SQL statements, so not only should you use bind variables, you should REALLY use bind variables.

Correlation != causation. You must be new here (said the guy with an orders of magnitude higher UID).

... or that your friends give them. Some of which may not even be your "facebook friends".

Do they make tinfoil hats as well?

They outlawed tinfoil years ago because it was too effective. Unless you're willing to settle for government-approved aluminium foil hats, which don't do a thing to block mind control rays, you'll have to do what I do. Dig up raw cassiterite from the back woods, smelt it in the barn and make your own tinfoil by smashing what comes out with a rock until it's thin enough.

While you're doing this, don't forget to drink only grain alcohol and rain water to protect yourself from the most monstrously conceived and dangerous communist plot we have ever had to face.

You may or may not agree with me, but since I am God, I am always correct and wise beyond your comprehension. You may not question me lest you run the risk of being turned into salt.

Okay. So the SCOTUS decided that it is OK to keep someone locked up beyond their sentence term because of what they MIGHT do? This isn't too far removed from rounding up all people on parole and sticking them back in prison because they MIGHT do something bad. This isn't too far removed from putting people who fit into a particularly risky demographic into prison because of what they MIGHT do.

The justice system that was created in the U.S. was created the way it was largely to remove itself from the ridiculous crap that exists in the British system... and now we're becoming just like them or worse. We shouldn't jail people because of what they might do. That is a slippery slope we don't want to slide down.

Try the application CellMapper from the Android market. It creates maps of user-submitted cell signal strength. Some of the areas you are interested in may be covered already, and any new data you submit will help to benefit the community as a whole.

Errors are inevitable. It's a little something called the Heisenberg Uncertainty Principle. Have you heard of it? No?

I guess the correct answer is maybe. But only possibly so.

    $3,500 is about average for a transmission built with R&R. If you're doing the labor, it may cost less.

    Some transmissions cost significantly more. Total for my ex's Honda CR-V was $4,800. That wasn't just us getting ripped off. I had several mechanics trying to source one for cheaper or even a used one, so they could get the job instead. That particular transmission only showed up in a single model year, and only on the Honda CR-V. As always, the less common the parts, the more they cost.