In a properly designed 3rd normal form database, you are correct. You'd never get to 255 columns. I can only think of one situation where it would be useful to have >255 columns and that is denormalizing a dataset for ease of reporting. For example a clinical-trials reporting database.

And now this line of code is used: IsEven (4.2); It'll bounce around 0 until the heat death of the universe.

No...only positive integers. Since this is JS, some jerk could pass a float in and get your recursive function to march off the negative end of the numbers.

Poorly

Super Lloyd wrote:

BTW Silverlight 3 is way more modern than Silverlight 1 (or even 2)

I have a (bad) habit of looking a MS technologies when they first come out. A couple of days invested there seems like a good plan. Unfortunately, MS has this tendency to "reinvent" the technology and just up the version number (and make the product actually good!). And here I am stuck with my 1.0 impressions :sigh: I actually had someone tell me that Sharepoint was actually usable now! Now you're telling me that Silverlight is at least "OK"! I guess it's time to take another look.

Do people actually use that cruft (Silverlight)?

So what's the problem with the default one? I've hit a few issues myself and always managed to get around them...:cool:

Actually he probably wants you to setup a 2nd computer with a webcam. Write an application that analyzes an image from the other computer's screen to determine if one of those dialogs is open, and if so send a command to power-cycle the plug the other computer is in.

Nobody has mentioned my first "owned" computer... A Radio Shack Color Computer. This had a 6809 based microprocessor running at a whopping 750kHz. With certain "POKE" values (found in RAINBOW Magazine you could double that!!). You could get memory of either 4K or 16K (with additional 16K ROM in both version). In later years I was able to upgrade to 64K. God, I loved that thing! Even its crappy chicklet style keyboard...

Wow, just wow. Most responders to the original poster sound like scary cowboy programmers :) Finally the correct (and only viable) answer.

Most computer books are trash anyway - they've become a bloated mass of repeated examples - they show the first 3 lines, explain them, then show those same 3 lines with 3 more added to explain them. Perhaps this type of organization is useful to some people, but I much prefer to see the whole example and then a detailed description of how-it-works. That said, I do prefer reading a book to learning/reading on-line. But for looking something up, Online is invaluable. One service I've used in the past was books24x7.com they have quite a few books on line (and searchable). Still not as good as having the book in front of you, but adequate.

Just in case you weren't aware of it, Google has a special "Code Search" feature: http://www.google.com/codesearch/advanced\_code\_search

Your DBA is correct - using a CHAR(1) is better than using a Bit field (sorry)!!! Here's the rationale: 1) Bit fields are not transportable - so when you move to Oracle you'll be able to do so with much less work. 2) Your CHAR(1) field can be marked as NULL (if desired). 3) Much easier for anyone querying the database with a non SQL-Server tool to get the results (go ahead and see what a product like Business Objects (or whatever it's called today) does with a bit field. 4) Bit fields are not part of the ANSI standard SQL. 5) Many CASE tools and Database Design tools do not support bit fields I disagree with your DBA on one point though! Limit the character to only the uppercase version of 'Y' or 'N' - even though SQL-Server is normally case-insensitive (unless you explicitly tell it not to be) many other database systems are not.

I did some consulting for a high-tech placement firm based in London (writing their candidate placement system). They told me that they wouldn't even look at trying to place a developer over 40 years old.