Microsoft needs to redress problems in Microsoft Access

So we fired Microsoft Access here at work. Access was fired for cause, without severance. What do I mean by that? Let me explain.

Most all of our work here revolves around Microsoft SQL Server 2005 & 2008. We use Access only as an export format, or a quarantine cleanup space for extremely dirty data. Some of our clients do like their data transmitted to them in Access format. We're going to stop doing that... almost immediately.

Microsoft has effectively ruined Access. Once upon a time, it the moral equivalent of a very useful Victorinox Swiss Army Knife for data. Now, it's pretty well worthless.

Now why would I say a thing like that? Two expert reasons:

1. At the moment Microsoft Access has no 64 bit API for database creation and manipulation.
2. Microsoft has destroyed the application itself with the Trust Center setting.

The first point spells out our primary affliction. We run a collection of websites that provide data to the 7,000-8,000 financial institutions of these United States of America. Some of those institution like their data served up on a platter of Access MDBs. We have supported this in the past, but no more.

Since we made the conversion to 64 bit mode, a conversion we found necessary due to the volume and complexity of our data, we've been experiencing serious issues supporting Access MDBs. We have re-discovered the following tangle of faux-solutions and problems.

1. The ADOX code we wrote years ago cannot be upped to 64 bit mode. ADOX is an ActiveX library. It is 32 bit. There is no such thing as a 64 bit ADOX library. Our old 32 bit code will run, but it breaks when upped to 64 bit mode. The COM library cannot be found and loaded. That is because a 64 bit ADOX does not exist.
2. If you are running SQL Server in 64 bit mode, you can forget about exporting Access MDB files. The 64 bit SSIS engine will attempt to lock and load the JET 4.0 engine, which is just a 32 bit COM library. Naturally, this fails. Tough shit.
3. We attempted to use SSIS packages in SQL Server (32 bit) to export the data in an Access MDB. We found this extremely cumbersome. The SQL machines and our web boxes are different boxes. Getting a SQL machine to deposit an MDB on a web server, or a mutually shared directory is a mater of opening more holes in the firewall, exposing more things to the DMZ, and there are timing issues beyond that. We also dislike the notion of keeping a 32 bit SQL Server in town.
4. We explored the possibility of writing .ACCDB XML files using XML Literals and compression. We were working on this very complex task when our customers signaled that they were not using Access 2007, and had no plans to go to 2010. The old MDB was demanded, not the new format. This effectively terminated our work.
5. There is currently no managed code (that is, C# .NET) library for manipulating Microsoft Access schemas in either the old or the new formats. Not even third parties such as the marvelous Syncfusion make such a library available.
6. Of course, we could continue running our 32 bit app, but this precisely the thing we want to retire.

This left us in a quandary. At the moment, there is no working solution.

COM is evil, and Microsoft is quite correct in killing it off. We don't want to see Microsoft up ADOX to 64 bit mode so our old code can recompile and run with success. That is not what we are after.

It is difficult to reason with clients about Microsoft upgrades. If they don't want to upgrade, we aren't really going to talk them into it.

I think I am going to finish the code that creates new ACCDB export, but I will do so privately. My company isn't interested. Neither are our clients. I do see a future value for this product. It will be worthwhile in the end. That should be the first Open XML OOXML managed code solution for the .NET framework.

As you can see, this leaves us hanging. We want to be comprehensively 64 bit from end to end. We want to flush the COM. We do not want ADOX, as it is both 32 bit and COM. We do not have a managed solution for producing the binary MDB. Neither does anyone else, for that matter. Our clients do not want .ACCDB.

Where do we go from here? The logical solution is to simply state that will not be supporting MDB anymore. We are simply phasing out that service. It has become to problematic.

I suppose this fits Microsoft's objectives of marginalizing the non-OOXML formats. This serves their end objective of applying upgrade pressure to their clients. I really don't like it. There aught to be a fully managed code solution for MDB construction. The net effect is that Access is going to marginalized by our firm and many others.

The second issue revolves around the utterly obnoxious Trust Center. The mere existence of the Trust Center--in this context--is proof positive that the lawyers are now running the software design process in Redmond. This is why we are seeing so many bad changes lately.

So what is the problem with the Trust Center in Microsoft Access? Aside from the fact that it utterly breaks any Access MDB/ACCDB solution, there is nothing wrong with it. Your app won't run until (under advisement that he/she should not) a user clicks "Enable Dangerous Macros". I say that breaks the application. The application does not work anymore. Further, breaking the app in this manner does nothing to protect the system. The very moment the user clicks "Enable Dangerous Macros", and the user must do this, all protection goes out the window. Microsoft would tell you this is a feature, not a design flaw. Stupid. Very stupid.

More stupid than selecting a QB #1 overall in the NFL Draft. Believe me, that's saying an awful lot.

The trust center effectively kills Access, shutting it down such that it cannot be used. If the application is so dangerous that it must be shipped in a lockdown state, it is too dangerous for public consumption, and should be removed from the market. If it is not that dangerous, the application should not be shipped in a castrated state for the sake of your legal department. Get a clue, Microsoft!

Frankly folks, this thing is utterly baffling. It's existence can only be understood as a stunt foisted upon Redmond software developers by the Microsoft legal department, who insisted on a disclaimer built into the package.

The problem with C# 4.0

I hear many things about my favorite programming language these days.  Not all are favorable.  Some statements conflict.  There are a couple of facts about the latest edition (additions) to C# that cannot be denied.

1.  Anders has added in support for dynamic language interop.  This is mostly a matter of implementing a new static type whose static type is dynamic.  I guess that is the C# way to do it.  Basically, a declaration of 'dynamic X;' means we will obtain a boxed object with some metadata attached to it to let us know what type it really is.  This is almost like generics in Java.  The performance penalty is not too terrible at run time when all factors are considered.  Still, there will be a penalty.  This won't be high performance.  Worse, there is no question that this is full-bore late-binding.  In any late binding situation, you loose type safety.  No compiler can ever predict that any piece of late-bound code will ever work, or work in all scenarios.  The compiler will go along with it, presuming that you know what you are doing.  When the build is successful, do not presume that the compiler has endorsed your code.

2.  Anders has added support for optional parameters, so we can now have pain-free use of C# in connection with the dreadful, much-detested, out-dated, out-modded Microsoft Office object model.  Optional params are big in OLE2 or COM or ActiveX or whatever you want to call that disgusting old shit we used to do.  Lamentably, the dastardly Microsoft Office object model is still a filthy COM beast.  You should obtain less painful interops with all COM servers because of Anders most recent additions to C#4.  Still... this is a dirty thing to accommodate.  It is the programming equivalent of saying "have sex with HIV infected individuals, just use this condom".

3. There is also some stuff about co & contra-variance with greater safety.  I have never stubbed my toe on Co & Contra Variance, so I see no issues solved here.  I suppose this helps in a few marginal edge cases.  I know of none in my code.

4. Finally, Anders & co are re-writing the C# 4.0 compiler in C# itself, thus making the compiler available as just another managed code software services at run time.  The presumption is that C# 4.0 programmers will now use this handy-dandy, ever-ready compiler to engage in meta-programming techniques and tactics.  Once upon a time, this was the exclusive privilege of people coded with Interpreters.  Java programmers can only get access to this sort of dynamism through a jar library called Janino.

These last two items are of no consequence to guys like me.  Some may be jumping for joy, but I don't need a runtime compilers just now.  

Surprisingly, the announcement of these language features has tripped off a debate surrounding the question of whether C# is getting too big for it's britches.  Some say that C# is becoming an over-bloated Swiss Army knife.  I really think this debate misses the point entirely.  The issue is not one of whether the language is getting too big, but rather whether it is growing in the wrong direction.

Certainly, I do not welcome the advent of the dynamic type.  I don't need it, and I don't plan to use it.  I suspect that the mere presence of this type will slow the compiler considerably.  I hope it doesn't result in generally fatter CIL for all, which would in turn lead to fatter X86 code.

I am not a fan of optional parameters.  Optional parameters are element & aspect of a generally sloppy approach to programming.  That is why they are in VB.  They are not unlike the unstructured goto statement.  They are just bad for your code.  Either a param is necessary or it is not.  If it is necessary, it should always be required, and it should always be set.  Programmers should not be allowed to 'safely' ignore a parameter. This is one of the many ways in which unexpected and somewhat unpredictable behavior emerges in a system.  Programmers should be aware of the change in behavior flag settings will produce.  Of course, I realize that Optional Parameters were big in the days of COM.  This is one of several reasons why COM was a dirty, fifthly, nasty, ugly, disgusting, detestable, nasty, wretched, leaky, buggy, unstable, evil piece of shit.  [Did I mention that COM had no security model and was single handedly responsible for the Great Spyware Pestilence of 2003?]  There are explicit reasons why we flushed COM down the toilet in .NET.  One of the reasons optional params were rejected in C# is that we wanted to rid ourselves of this corruption.  Now here we go again.  Not good.

I understand why Anders reversed himself.  Many, many, many C# programmers have been bitching for years about how difficult it is to drive the Microsoft Office Model because C# does not support optional params.  Anders caved in under pressure from customers and the high command.  In a very real sense, I know this will make my life easier when I must do an Office automation project.  Still, I do not look forward to fully managed C# library, with no element of COM, which show optional params all over the place.  This eventuality will signal the arrival of sloppy coding techniques in the rather purist world of C#.

My real bitch is that the two language features we really need the most did not make it into C# 4.0.  What are those features?

1.  Traits, just like in Scala

2.  XML literals just like in VB.NET

In all honesty, these are the only two linguistic innovations I have seen in the past 6 ot 7 years that did not originate in the C# project.  

Traits are basically implemented Interfaces which you can tack on to almost any object.  They give you the advantages of interfaces with the advantages of mixins in Ruby.  The final yield is a language feature which gives you the reliability of single inheritance with some of the advantages of multiple-inheritance.

XML literals threw me for a complete loop.  XML literals took VB, a language which was dying IMHO, and suddenly made it the best language for the MVC framework. You don't know how much it hurts me to say this, but I would never want to code a helper class in MVC without the aid of VB.NET XML literals. This is not to mention all of the complex XML transforms which this system makes incredibly easy.  

XML literals are probably the greatest, most practical, most useful idea I have encountered in the past 5 years.  The biggest thing since Generics.  Scala also has a form of XML literals, but they don't seem backed by the sort of library power VB.NET offers.  In any case, C# should have had this feature.  Omitting XML literals from C# 4.0 is the same thing as capitulating the MVC framework to VB.NET.  Anders needs to take notice of this fact and make some corrections.

So the final verdict is clear.  C# is not guilty of getting too big.  C# is guilty of expanding in the wrong direction.  C# is guilt of not expanding in the right direction.  All-in-all I am quite disappointed.