As I mentioned in my previous Dot Net 4 strategy blog entry, we have been thinking about how we want to handle Dot Net 4 from an API and runtime standpoint.

Just as a little refresher, remember that when I am talking about a .Net 2 assembly it can actually be any of the .Net 2, 3.0, 3.5 or 3.5 SP1 runtimes.  They are a layered cake design in that they all use the same base and build up with additional tiers of functionality.  You cannot have a .Net 3.5 app without .Net 2 present, doesn’t exist.

In VistaDB 3 and 4 our core engine is .Net 2.0 SP1, and in VistaDB 4 the Entity Framework assembly requires .Net 3.5 SP1.  So everything mentioned in this post equally applied to VDB3 and VDB4 applications.

.Net 4 app loads .Net 2 API

Any application (executable) built under .Net 4 will have it’s dependent assemblies automatically promoted to .Net 4.  You will not be able to have controls run in a side by side version of the framework because there is no way to communicate across the .Net runtimes.  For example there is no way for a .Net 2 Winform control to communicate to a .Net 4 hosting application if it is not auto promoted to .Net 4.  In order to do this type of thing you would need to use COM or some other cross process communication mechanism.

But what about applications that are unmanaged (think Office)?  Which runtime will they bind against to load plugins?  It turns out the answer is “it depends”.  The runtime loaded is based upon what runtime the plug-in was built against.  Your .Net 2 application will not auto promote to .Net 4 just because some other .Net 4 plug-in is loaded by Outlook (as was the case with .Net 1.1 apps with 2.0 installed).

Enter Side by Side

It turns out there is an interesting new feature in Dot Net 4 to allow side by side running of managed runtimes within the same application.  There is a great CLR Inside Out article online that explains probably way more than I will here, but I wanted to point out a few specific parts of the article and how they impact API writers like VistaDB.

Library Developers and Consumers: In-Proc SxS does not solve the compatibility problems faced by library developers. Any libraries directly loaded by an application—either via a direct reference or an Assembly.Load*—will continue to load directly into the runtime and AppDomain of the application loading it. This means that if an application is recompiled to run against the .NET Framework 4 runtime and still has dependent assemblies built against .NET 2.0, those dependents will load on the .NET 4 runtime as well. Therefore, we still recommend testing your libraries against all version of the framework you wish to support. This is one of the reasons we have continued to maintain our high level of backward compatibility.

-from “In process Side by Side” by Jesse Kaplan

.Net 2 CLR gets promoted, but what about the other way?

This is interesting to me, as we were sort of hoping that we could load .Net 2 CLR Procs in their own side by side so they have the runtime they expected when they were built.  Now the behavior is non-deterministic.  The runtime the CLR Proc gets will be dependent upon the executing application.  So if you load a 2.0 CLR Proc in a Data Builder built for .Net 4 your CLR Proc will run against .Net 4.  Maybe that is ok, but maybe it is not what your CLR Proc was expecting.  But the other way is impossible…

Let’s say you build your CLR Proc against .Net 4 and install it into the database.  Now you use that database in an IIS hosted site that only supports .Net 3.5 SP1.  The CLR proc will fail to load!   Older runtimes cannot load newer runtime binaries.  This leads to some very interesting edge cases in the VDB4 database.

More...

Do you have the complete .Net framework memorized and know every class from the back of your hand?  (Wow, impressive if you do)  Most people cannot remember that much information.  Back when all we had was the paltry C runtime library I knew guys who reveled in their esoteric knowledge of functions and overloads.  Yes, this was back in the days before we had the fancy Intellisense in our IDEs…  I am sure many of you remember.

Never memorize a process or procedure

I learned this the hard way when I was in the military.  You should never memorize a process or procedure – the documentation on it could have changed since the last time you did that operation.  You always had to go get the book and follow the steps.  In this case the books were a hefty series of volumes on UH-1H (Huey) maintenance.  The books totaled about twenty 5 inch binders, that each weighed about 15 lbs.  No one wanted to go look up the process each time – took too long and the darn books were too heavy.

I was a young 19 year old (yea, it’s been a while) that ran off one day to do a test.  I had to pull a transmission filter suspected of metal contaminants' and replace it.  Then turn in the old one for inspection.   Easy stuff, I was thinking.  I had done this task a dozen times before in training sessions – I didn’t NEED the book.  Got my tools, ran out to the flight line and did the procedure in about ten minutes time.

Got back to the TI (Technical Inspector) and turned in my paperwork.  He immediately asked me what the last revision was on the manual I used for the procedure (each book has a revision number in the front to tell you when it was last updated and what the minor changes were).  I rattled off the number I had seen yesterday on the book.  He looked at me for a long time (first clue you really screwed up), then sent me off to the lead instructor.  I then ran about 5 miles around the flight line while wondering what I had messed up.

Did you read the manual?

When I returned from my little “thinking time” run the Chief Warrant Office asked me, “Did you read the manual?”  No point lying at this point, “No Sir!”.

If I had read the manual (that day) I would have known that the procedure had changed the previous night.  A new manual “patch” had come in the previous day and been applied that night.  The process had been changed to include a new step for swapping a gear while you had it all apart to get further insight into the gear wear pattern.  By skipping that step I had just invalidated the entire process, all my results on the metal analysis would be wrong.  To drive the lesson home I was assigned additional duties for my lapse in judgement.

I got to think about it, and then present a series of “remedial” lectures to my fellow soldiers about the virtues of always reading the book, and about the dangers of thinking you know the answer before you start a task. 

Needless to say the lesson did stick in my head

To this day when I go to assemble something I read the instructions first.  I go through them to make sure there is nothing unexpected.  When I get a new piece of software I always look at the release notes to see if something I was expecting might have changed.

And I never assume that an object is going to do something without actually reading the current information to ensure it still does what I am expecting.  This is a lot easier today with Intellisense, you can get the quick information on the function directly while writing code.  Make sure what you think it does is actually still there.

Don’t memorize, but know how to find the information

In a recent job interview with an intern I asked him some arcane information that most people will not have memorized.  He told me that he didn’t know the answer, but he knew how to look it up and find out.  That is what I was looking for, a man not afraid to say he doesn’t know; but does know how to find it.

More...

We get this question so often in tech support, that I wanted to post a quick tip that hopefully people will find useful.

Remove the time part

To remove the time part from a datetime you can do it the following ways in both SQL Server and VistaDB.

   1:  -- SET SOME DATE WITHOUT A TIME (doesn't matter what it is)

   2:  declare @somedateonly datetime;

   3:  set @somedateonly = '2000-01-01 00:00:00';

   4:  SELECT DATEADD(dd, DATEDIFF(dd, @somedateonly, GETDATE() ), @somedateonly );

You could also do it in a single statement like this.  The date doesn’t matter, just that it does not have a TIME component.

   1:  SELECT DATEADD(dd, DATEDIFF(dd, '2000-01-01 00:00:00', GETDATE() ), '2000-01-01 00:00:00' );

How does this work?

The calls are really subtracting the number of days from the GETDATE() call and the entered date. Then it adds the difference to the entered date (which contained no time). The end result is that you have the date without a time being set.

More...

There is this myth among developers and DBAs that SQL Server has a natural order that is logical and predictable (and can therefore be relied on).  Not so!  I wanted to take a few moment to explain and debunk the myth, explain how VistaDB is different, and share something I learned along the way.

The Myth(s)

• SQL Server stores entries in a natural order based upon the first column.
• SQL Server always appends inserted rows at the end of the current table.
• Unindexed data is always available in the order it was inserted.

Have you heard those as well?  In most databases an insert is always appended to the end of the current table, this is for ease of insertion and for multi threading where you want to lazy write to the database after the insert (of course servers can get away with that, but we can’t because we don’t know when your application will go away and kill us).

You can’t actually count on ANY of those from SQL Server.

Select * always returns the same order

Many times developers pull a SELECT * from the database in SQL Server and think the order will not change – IT CAN CHANGE.  If you do not explicitly put an order by clause on your select you have no guarantee of ordering in SQL Server.

EDIT

You can read the full explanation why this happens over at the SQL Serverpedia blog entry on natural order.   I am not sure if this was the original or a repost from Brad's blog, but I wanted to give credit to where I originally read it.  The article at SQL Serverpedia was emailed to me from a user asking about how VistaDB works in this same situation.  I then got the same article from 2 other users in the same week...  Sounded like a good time to do a blog about it.

As was pointed out in the comments below, the original article came from another blog.  Brad Schulz did the original article on this topic and you can read his blog for the complete details.  Trust me if you love SQL technology you will love that article.  It is very well laid out and explains everything in depth that only a true SQL geek can love (like me!).

Take a look at this SQL:

create table ordertest 
(
  col1 varchar(900) not null
 ,col2 char(1) not null
);

-- STEP 1 insert some data
insert ordertest values ('B'+replicate('.',899),'N');
insert ordertest values ('R'+replicate('.',899),'A');
insert ordertest values ('A'+replicate('.',899),'T');
insert ordertest values ('D'+replicate('.',899),'U');
insert ordertest values ('S'+replicate('.',899),'R');
insert ordertest values ('C'+replicate('.',899),'A');
insert ordertest values ('H'+replicate('.',899),'L');
insert ordertest values ('U'+replicate('.',899),'O');
insert ordertest values ('L'+replicate('.',899),'R');
insert ordertest values ('Z'+replicate('.',899),'D');
select * from ordertest;

-- STEP 2 insert two more values
insert ordertest values ('X','X');
insert ordertest values ('Y','Y');
select * from ordertest;

What do you think the first and second select statements look like?  The first is probably what you expected, the second probably is not!

More...