The magic happens in the Repeat.Times(1) statement. This tells Rhino.Mocks that when the method is called, the mock should Return the given value that number of times. After that it can return a different value.

Update: Jeremy Miller told me about the DataTableReader class in the BCL and that you can use it to stub out IDataReader. I like this better because it removes the dependency the test had on Rhino.Mocks.

I don't remember where I got this split function from. I know I didn't write all of it from scratch. But basically what it will do is take a delimited list of data, split it apart, and return a table where each data element is associated with the identity value you pass into the function. This is very useful if you just want to get the values for a single row.

So what happens if you are trying to build a view or a report and need to split apart multiple rows. You can iterate over the rows in the table you want to flatten out and call the split function for each row, passing the rows PK into the split function.

This function uses one of my favorite sql tricks. It uses a while loop to avoid having to declare a cursor . The logic is pretty simple, on each loop, select the lowest value of the PK in the table that is higher than the previous PK. That's the roundabout way of saying, "Select the next highest PK from the table".

Right now, this function is hard coded to flatten the table "MyTable", but it could be re-factored into a general use function.

The unfortunate side effect of this is that the SQL users in each database are no long associated with the SQL Login. SQL Server has had an sp called 'sp_change_users_login' since SQL Server 2000. You can pass in the 'Auto_Fix' parameter and the name of the SQL user that is orphaned and SQL Server will do it's best to automatically match the user name up with a SQL login. There are a few gotchas that the MSDN article, and people better versed in SQL Server internals than I, can spell out. But for 90% of the cases out there, this SP will work fine. But it only works on one user at a time. So I created the world simplest code generator to help me create all of the statements needed to attempt to reassociate my users with their logins.

uid 2 is the guest account and uids > 16000 are the built in "db_*" users.

Nothing else matters once you hit the disk. Once you do any kind of activity that involves reading/writing to a hard disk, that activity instantly becomes your greatest performance drag. No matter how slow any language is at interpreting/JITing/compiling, it's still orders of magnitude faster than interacting with a hard disk with physical, moving parts.

Especially when NOT being able to tell the difference would result in over 500K duplicate inserts every day. (especially when the reason you've asked him that question is because you noticed his DTS package would result in the 500K dupe inserts/day).

grrrrrrrrrr

But then you start to look at the data sets that supercolliders turn out. These supercolliders can churn out 10 petabyte (10^15 or 2^50 bytes) datasets each time they run. Some astronomical data sets run into the 10PB/year range. None of these are in a RDBMS yet. None can handle that much data all at once yet. Datasets in this range fascinate me because I can't really visualize a multi-TB dataset, let alone a single petabyte. I know that some of the researchers here have multiple 100+GB Firewire external hard drives chained together holding DNA and protein sequence information. Usually in hundreds and thousands of Excel spreadsheets(groan).

Check out this PowerPoint by Jim Gray of MS Research where he talks about some of the larger datasets. Interesting that Google was a 1.5PB as of spring 2001. WAY before the GMail initiative or Google Video upload. I wonder where they are now?

Matthew is having some problems with Oracle. I don't know why he would inflict that kind of pain upon himself, but my guess is it's client driven. Damn clients.

I briefly had to work with Oracle 8i at a previous job. I couldn't figure out any of their gui tools, half of them wouldn't install correctly and I think it took about 2 hours to get to the point where I realized I couldn't install them. (This was back in the Win2K days, not the halcyon days of hmmmm, damn guess I'm still using Win2K. In any case RAM was more expensive so we didn't have a lot.) I ended up just writing all my DB creation scripts in ViM and running them in SQL+(I think that's right).

Then they laid off the DBA, who promptly too the admin password with him off to Vegas (Las Vegas, NM). Of course when we called him up and asked him for the password he couldn't remember it. Thus began our forced migration to SQL Server. I couldn't log into any admin interface in Oracle, but we did have a user account that had read access to all of the databases. Yay! So I ended up linking them Oracle server to my SQL Server and using DTS to migrate the data over.

Pick up "Writing Secure Code v.2", They discuss how a SQL parameter can be used as an injection attack.

Mostly, the examples I've seen center around the "exec" statement, either embedded in the code or in an SProc.

sqlString = "exec sp_DoSomeStuff '" + inputFromUser + "'";
SqlCommand cmd = new SqlCommand(conn,sqlString)

But Ellery makes a couple of his own.

Prefixing your variables with the type (i.e. sName), is not very .NET. Reason for this being that your variables are suppose to have meaningful names which allow their type to be identify without the need for a prefix. Itís pretty easy to see the variable types of firstName and dateOfBirth. I believe most people who do this are/were VB programmers who canít get rid of the habit.

So what's the type of dateOfBirth? Does it return a string? Is the date it returns a DateTime short date string or long date string? Does it return a DateTime type? Do you have to hover over the var name to find out? How much time does that take our of your day, trying to find the right hover spot in Visual Studio?

In Wesleyís code, the SqlParameter does nothing but introduce unnecessary overhead and code complexity. You can provide parameters to a stored procedure by simply executing it in the SQL code (i.e. ìEXEC usp_GetUserDataByID 257;î).

Yes, that's a great idea provided that Wesley doesn't care about SQL injection attacks? Concatinating together an "EXEC" statement to execute a stored procedure is almost as bad as concatinating the SQL string together.

Although not seen in this code example, he ALWAYS sets the CommandType property of the SqlCommand objects, even when he needs CommandType.Text. Text is the default value for that field. No need to set it.

You should never rely on the default properties of classes and methods. What happens to your code if the default property or the underlying enum is changed? Ellery has some learning to do to.

Hank Fay hits upon a key piece of information that no one is mentioning in all the press/blog entries surround the rolling of Object Spaces into WinFS.

Question: will this merger create unbreakable tie-in between ObjectSpaces and WinFS, such that other relational datastores (think Oracle, MySQL, PostGreSQL, DB2, Firebird, etc.) are no longer in the picure? Or am I missing something here?

Nope Hank, I'd say you are right on target. Unless MS plans to make the ObjectSpaces provider pluggable (e.g. a FileSystem provider, a Sql Provider, a Exchange Mailbox provider, etc...) I'd say that's exactly what Microsoft is hoping for.