Regarding microsoft online content. It seems there is a lot of content at a high level from the marketing folks and a lot of specific content at a low level from the techies but there is a lack of bridge content that links the two and gives context about the topic (past, present, and future).
@spivonious: Can you share the specification doc that was given to you from which to create the example app? If so upload it to skydrive and post a link. I'm curious.
Depending on the specifics in the doc I wonder if you could create a solution that addresses all the requirements using tools and technologies you already know. I know that wasn't the focus of the hiring party but this is to address the hurt confidence.
It probably would set off a marketing war but it would be nice if the Microsoft marketing group put out just as sarcastic a material set. They put their big toe in the water with the phone commercials showing folks getting in and back out of the phone. That was a wonderful smack on the piddling behaviors developed with other devices.
@Jaz: If a whole set of scheduled tasks stopped working at once then i'd suspect an authentication failure.
If all the scheduled tasks were setup using the same account then check the account to see if it is a local or (as w3bbo states) an active directory account.
If the account is a local account then they may be relying on matching user/password passthrough between machines. Check both machines involved and make sure both sides have the same user/password combination.
If the account is an AD account then follow the security chain to verify that the account is in at least one security chain which provides sufficient access for what the scheduled task is attempting to do on both source and destination machines involved.
At the very least the scheduled task account will need:
1. Ability to connect to the destination machine.
2. Ability to traverse the destination's directory tree or whatever specifics the scheduled task does.
3. Ability to traverse the directory tree on the source machine.
What? The shotgun blast approach isn't fun! Hang back a little bit. Big companies have the resources to throw ____ into the fan and see what sticks. Its a viable business strategy.
If your feeling like the technology being depended on could get yanked out from under you then its time to make some changes that limit the exposure. I'm not saying new technology shouldn't be used but take some precautions to protect the code base. Don't forget that we used to do this all the time with other vendors when the Microsoft's stack wasn't as broad.
ID, K, 4B - why would writing that to a flat file be larger that what SQLite would use? It can't be. Your not having to store any of the overhead related to the engine.
Since your records are inserted in order by both ID and K you could store in a flat file and be able to read back fairly well, although you didn't mention much about the requirements of who/what needs to get this data that has been stored. If there is a need to retrieve data records out in relation to other data then taking the flat file route will tend to force the other data being related to be in a similar storage mechanism (i.e. less friction in the relation). We need to know more ...
What will the 1 billion records be used for once they are stored, regardless of SQLite or flat file? Fast Min/Max for what (the first record is the min, the last record is the max, so there must be more to this).
What time duration targets for storing the 1 billion records must you beat?
I am having a tough time seeing the publicity for Einhorn's comments as anything more than media furvor.
Ballmer has a much larger piece of his cheese at stake.