I ****ing Hate Microsoft Access

I posted this on my Google+ page, but since I'm sure many of you (ok, most of you) don't ever go there, I'm reposting it here because I'm still pissed off...


Time to Vent...

Microsoft Access is evil. It is the worst God-forsaken piece of shit ever perpetrated on enterprise customers in the history of mankind. It has held up migrations of Office suites in more places than I have days to count. The notion of bundling applications WITH databases is as stupid as riding a bicycle off a cliff. I fucking HATE that application. My teeth are clenched. This is not good. I must continue...

God****it - Access has wasted so much time of so many people's lives that will never be recouped. I can almost forgive IBM for OS/2 Warp, and Autodesk for R13, hell I can even forgive MS-DOS, but I cannot forgive Access. What a fetid turd of technological vacuousness. Is that even a real word? Vacuousness? Whatever. I made it up because thinking about Access pisses me off.

Is there any shortage of reiterated emphasis on "de-coupled" application logic on MSDN? On TechNet? On ANY programming site? Publish a rule and break it. Just as I blogged about with the Configuration Manager AD publishing guideline, but whatever, I need a glass of wine now...

Today makes at least two dozen situations, over the past 12 years, where a customer has to hold up everything because the dipshit department is arguing over upgrading their craphole Access "application" and who will pay for it (you know: "We think YOU should pay because YOU are forcing US to upgrade to 2010" versus "We think YOU should pay because YOU made a stupid garage-app piece of fucking shit mistake that WE are having to pay for in lost time and productivity") Wash - Rinse - and Repeat - AGAIN.

The Never-Ending War: Centralized IT vs Department Developers

I doubt any of you will read this one to the end, and I can't blame you.  But I have to say that this is probably one of my best articles so far.  It's one that I'm fairly passionate about and it shows in my verbosity.  I apologize for torturing your eyeballs in advance, but I must go on.

For many of you, this scenario should sound pretty familiar:

A large corporate business evolves over decades to the point where they decide it makes sense to centralize their IT operations.  They create a new department and appoint a CTO or CIO and staff the various functions.  Prior to this, it was common to find each department building and maintaining their own unique software applications to solve their own internal business needs, aka "line of business" applications ("LOB" for short).  In decades past, it was dBase or FoxPro.  In more recent times it's been Microsoft Access or Excel.  Quite often, it involves VBA code.  Lots and lots of VBA code.

The centralized IT department strives to gather all of the LOB applications and apply some centralized procedures to maintaining it.  Maybe the company is trying to be ISO or CMMI compliant, or maybe ITIL, or whatever.  Who knows.  In any case, the MBA mindset comes to the logical conclusion that redudant job roles are expensive and inefficient, especially when one person in Finance is building roughly the same application as the person in Sales.  These isolated, parallel and typically redundant efforts have no incentive or desire to coordinate efforts with other departments due to politics and funding, so they march on unrestricted for years.

When IT finally gains control of a few of the key LOB applications, they apply common ITIL or CMMI procedures on change control, which invariably slows down the process of implementing updates.  The LOB folks quickly grow tired of this, and eventually pull away from IT to continue building their own applications.  The cycle continues.

This is often referred to as a "NO-WIN SITUATION", because that's exactly what it is.

The top management folks are left with two options:

• Ignore it and leave the fighting to the lower level managers
• Stress out trying to make a decision over which is the lesser evil: inefficiency or inefficiency.

The two greatest risks facing them are:

1. Allowing the redundant waste of time and resources to grow unchecked (because it's NEVER really checked) and allow inconsistent results to spread.  The practice increasingly melds the company core business processes to hundreds of tiny little tools built by people that have worked themselves into a position of necessity (cant' fire them or you risk being stuck with a broken tool and a busted business process)
2. Forcing the LOB apps under the control of the IT department, becoming painfully slow at responding to surge-capacity, and frequent requirements changes.  Everything must now be vetted, developed, tested and implemented under the new procedures.  No more "walk-up" requests.  No more Summer intern kid-turned-full-time-developer to handle your needs.  LOB requests now get routed through a load-sharing process to "resources" which share their precious time with other (possibly competing) LOB requests.

Ugliness.  Bad feelings.  Animosity.  All that kind of stuff.

This is one of the reasons I F-ING HATE MICROSOFT ACCESS

The product itself is not bad or evil.  Fire isn't bad, when used properly.  Each serves a noble purpose.  But fires created by a small group of trained professionals is one thing.  Handing every person in a 10 mile radius a can of gasoline and a box of matches is a little different.  Server backended applications are like the trained professionals.  Microsoft Access is like a truckload of gasoline cans and matches being handed out like rice bags from a UN truck in Rwanda.

The most common scenario today involves this vicious cycle of stupidity:

• The Sales department asks a promising Summer intern to build them an uber sales tracking app.  Uber-brainy intern cracks open a "Access VBA Unleashed" book, and builds the new application in MS Access 2000 using lots of VBA.
• Years later, the company decides to take advantage of volume licensing and buys into a SELECT or ENTERPRISE AGREEMENT contract to get upgrades more cheaply. The Company recieves licensing for Office 2010 and wants to upgrade all computers ASAP.
• The Sales department cries that Access 2010 will break their LOB app.  They cry to upper management. IT is ordered to put the upgrade plans on hold.
• The IT department now decides on one of two courses of action:
  • Dedicate several developers to re-developing the application to work in Access 2010, but they don't understand the LOB requirements or logic, so they have to work closely with the Sales department to gain better understanding.  They also have to decide how to address deprecated functionality (from Access/VBA 2000 to 2010), and incorporate new features, or if there is even enough time to do that, or just patch it up and make it work.
  • Dedicate several developers to shoehorn the old application to work via the Access 2000 runtime engine, if that even works (sometimes it does, sometimes it doesn't).  This often becomes a mess, with file associations getting corrupted and interaction issues with other third-party applications.
• The plan to deploy Office 2010 is now sidelined until they can adequately resolve this dilemma.
• By the time a solution is reached, Office 2012 is released and the process repeats

Either way, it ends up being a long, drawn-out waste of time, money and effort.  Sure, it can be argued that it's not a waste because it's provides (hopefully) a workable solution.  But if the entire problem COULD have been avoided by adopting proven practices, isn't that ultimately a waste?

A database is a database.  It should be used as a database, not as an end-user application platform.  Client/Server or web-based interfaces would easily decouple the functionality from the data store.  Then if the only thing that changes are the database connection parameters, you don't have to rewrite the entire application.  In many mature development environments, this is considered programming 101.

You probably won't believe me, but I actually do get sick of hearing myself talk and get queazy reading my own drivel.  But painful as it may be, I must go here...

Over-Caffeinated Rant (deep inhale, and....)

I haven't really delved into the virtues of decoupled business logic in n-tier applications architecture.  There's an enormously powerful incentive to following this time-tested and well-proven approach, which is along the same lines of logic as multi-stage code compilation, assembly line production, and zone defense in team sports.  That is, that compartmentalizing certain logical blocks of functionality make those blocks portable and flexible.  It makes them more easily (and more affordably) adaptable to future changes.  You know, those future changes that are quite often unforeseeable and unpredictable?  It also tends to make those newly defined blocks more efficient, both in construction and execution performance.

But things like n-tier business logic and decoupling are rarely familiar terms to the Summer intern who happens to dig tinkering with VBA (or VSTO) within Office applications like Excel and Access.  To them, it's just fun to code, and who can blame them?  How do you effectively convince this wunderkind teenager that "fun" isn't as "cool" as decoupling your code and applying standard design prinicipals to it before ever punching a key or clicking a mouse?   It's a serious conundrum for businesses of all sizes, but particularly insidiuos and debilitating for larger corporate behemoths due to their scales of inefficiency at all levels.  Who is the best equipped, and motivated to insert themselves into this vicious chain reaction and disrupt it entirely: IT, LOB stake-owners, or senior management?  IT rarely has the global authority to stomp out such wildfires alone.  LOB stake-owners rarely have the global incentive.  Senior management doesn't give a shit because that's why they hired mid-level management to insulate them from.  When LOB stake-owners are coupled with mid-level management (often one and the same), it's a done deal: nothing is going to improve.  This is the most common scenario in modern corporations today.  A Catch-22.

My coffee just ran out.

Rant Time Again: Microsoft Access

This started with a brief post on Facebook, but I felt it necessary to expound upon this with a little more digressive digestive congestive festive and restive zeal.  Enough of that already.

Where do I begin.  Hmmmm.  Finger's are tapping…  Here goes:

I hate Microsoft Access.  I despise it.  It might just provide enough evidence that "evil", as it were, can and does in fact exist, even in the skeptical minds of agnostics and atheists.  My atheist colleagues would likely say "there is no 'evil', there is only man; trying desperately to blame some ethereal scapegoat so as to avoid responsibility for his own actions".  That may be true.  I'm not Nietzche or Wittgenstein, so my rebuffment to this would be "Oh yeah?  Well, then, what about Microsoft Access?! Hmmmm?!"  At this point they begin stammoring and stumbling and stuttering and hemming and hawing. I've handed their Superman belief system a fresh wheelbarrow of Kryptonite.

Less educated folks would respond to my response with "Well, Mr. Rational - Access was created by man, so it still qualifies as wrong-doing by man, not the transendental force called 'evil'".  I ignore them and continue picking my nose.  Confident of my superior defectiveness.  Those with a greater understanding of it would then be nodding and saying something like, "Sorry buddy.  Access transcends the potential evilness of mankind alone.  It digs down to a whole new level of treachery and depravity."  And then they'd all form a line to the Confessional and heavy drinking.

Where was I?  All this quasi-intellectual bullshit I'm spewing forth… Oh yeah…

When Microsoft decided to bundle this little land mine called "Access" into their Office suite, they essentially created a toolbox in the shape of a crack pipe, that enticed idle fingers to begin doodling and tinkering.  If they would have simply used it as a "database" and left the GUI (forms, reports, etc.) to REAL applications, things would be fine. 

But noooooooooooooooooooooooooooooooooooooooooooooooooo…. 

They HAD to build "applications" inside of Access.  Thus began the existence of the Taliban.  Darkness and horror suddenly had a new face.

Everyone working in an IT department of anything resembling a large business, corporation, municipality or Federal organization is nodding in full agreement already.  And if they're not, well, they are idiots.  Why?  Because…

As soon as these garage mechanics turned NASCAR professionals throughout our office departments everywhere started dabbling with Access and building "mission critical oh-my-f***ing-GOD-our-company-will-self-destruct-if-you-take-away-this-mission-critical-oh-my-GOD-access-application", they essentially created what is now referred to as the "shadow IT operations" of our world.  They spent company funds on MS-Access self-teaching books ("Access for Idiots", "Access for Dummies", "Access for Asswipes", "Access for Pedophiles", and so on).  They spent hours building tables, queries, and then (I get nauceous at the next few words): forms, reports and VBA code to glue this festering pile of rotting carcas meat into a "business application".  One or two was expected.  Three dozen were born in the first month, and they've only multiplied exponentially ever since.

But, as Ron Popeil would say: "But wait!  That's not all!"…

Then came the revealing moment of true evil: The next Office upgrade.  When they tried to open their little wunderkind uber-creations in the newer version of Access, guess what happened?  Go ahead. Take a guess.  A wild guess.  I'll wait….     That's right - they crashed. 

The solution?  Upgrade all the stupid Access trashware crapplications (heavy emphasis on the plurals).

The Results?  --- IT was typically forced to hold off deploying what would otherwise be a routine Office upgrade, because this Access "oh-my-GOD-we-have-to-have-this-or-Revelations-begin" database "application" with crappy VBA forms that required hours and days and weeks of upgrade torture and testing and more torture - IT was forced to shelve it for months, often a year or more.  Has this lessened?  Subsided?  Relented?  Hell no!  There are just as many of these little six-legged pieces of fecal matter running around as ever.

The feeling in the pits of our IT stomachs, after being ordered to wait for the non-qualified simpletons to do their own upgrades, was about the same as what an OB-GYN would feel when being told to wait while the stumbling husband setup the video camcorder.

We tried.  IT folks begged them to move their data into SQL Server or Oracle.  They refused.  We tried to educate them on de-coupling.  They blew us off.  We cried to management, but the little weezels got there first.  Today, we sit in meetings that still end up with someone going "well, HOW are we going to move forward with all these Access database apps?" with a tone like a bad Victoria Jackson impersonation.

It started with Access 97.  Then they had to hold everyone up while they upgraded it to Access 2000.  Then again for Access XP (2002), and again with 2003.  Then another upgrade to Access 2007.  And now we're suffering through this mind-numbing cesspool of idiocy to get to Access 2010.  "Wait!  You can't deploy that upgrade because ---" 

IT cuts them off …

"yes, we know, because you need a few months to upgrade the ****ing piece of **** Access **** you insist we never migrate into a REAL application environment.  All in the name of YOU justifying your pathetic existence and diversion of corporate funding away from our training budget and Summer picnic and all that.  Go ahead.  We'll wait.  Maybe by the time Office 2014 ships you'll have it ready for Office 2010.  That's fine.  Not like we need to improve any efficiencies around here."

Want a little entertainment?  Walk over to one of your overzealous Access "developers" and (with a straight face) say "So, did you get the word that we're moving all the Access databases into SQL now?"  Then stand back and watch them implode.  It's like taking crack from an addict.  I've actually tried this.  It ain't pretty.  I almost felt sad watching them have a complete mental meltdown and defending their application as if pleading for their life at gunpoint.  Sad.

Can you tell I ****ing HATE Microsoft Access?

Yes - you will now have the urge to say "But Dave, Access is a great little app!"  Yes.  By itself, it's not a bad thing.  It's what it ALWAYS gets glued into that ends up screwing up IT operations everywhere.  Thousands of Access database apps, culled and coddled together by hours of self-learning effort, in the name of impressing the co-workers and the boss and making themselves vital to the company.  And when these self-made Access folks speak up in a meeting to say we should use Access as the backend to all of our intranet portal apps, with thousands of employee users - I grit my teeth to the point of shattering them in little pieces.  Anger.  Anger!  The angst is overflowing… breathe…. breathe…. aaahhhhhh…. mmmmmmmmmmm…. happy thoughts - yessss…. happy thoughts.  It.will.be.ok.  Aaaaahhhhhhhh….. mmmmmmmmmmm…

Epilogue -

The council has voted.  Dave is now supreme leader of the cosmos.  The emperor of the galactic federation.  He emerges from the ominously tall heavy wooden doors, sauntering casually down the long polished marble walkway to the grand podium, to greet the masses, cheering in elation at the hope that has now, finally, materialized into the promise.  The promise of a better tomorrow.  So much hope.  So much pent up excitement at the potential he brings to the Universe.  He approaches the podium.  The gathering masses begin to quiet.  They await his first words… shhhhh…. he speaks:

"My fellow galactians, or, er, uh.. whatever the **** you call yourselves.  I have decided to begin this first day of my administration with the following decree:  All instances of Microsoft Access are to be vaporized immediately." (massive cheers).  "And… anyone, speaking in favor of this horrific little beast shall be dunked in ice water and then lit on fire and tossed into a nuclear wood chipper.  Any questions?"  after the long silence… "Good.  I didn't think so."  And again the masses erupt in cheer.

Script to Import MS-Access 2007 data into SQL Server 2005 table

Before you start throwing your hands in the air and exclaiming “see? I told you!  This guy is a dumbass!  Anyone with any experience using SQL 2005 knows you use SSIS to do this!”, I know.  And I agree: it is the way to go.  But (yes, there is a but) you may be forced to deal with this situation without having SSIS at your disposal.  I won’t get into reasons why this could be, but suffice it to say it does happen.  So there are options a-plenty for you to pull this off.  One of them is using a script.  Any script.  It doesn’t matter what language really, as long as you can connect the pieces together and move data across.

This is just ONE example, using VBScript and ADO to connect to a Microsoft Access 2007 database file, fetch the results of a query, connect to a SQL 2005 instance, truncate a temp table, copy over the query record data, then roll that over into a final table.

Why the temp table?  Because it adds a buffer layer of safety and performance in the middle.  On the safety side, it helps to ensure you get valid results from the source query before doing anything more.  If that fails, you exit and notify that the source shit the bed for some reason.  If it succeeds, you pull the data over into a temp table first, then copy it from there to the final table.  This last step provides a boost in performance.  If you have applications or other SQL views relying on the final table data, you want to keep the window of time during the import as short as possible to avoid interrupting those other services.  It’s much faster to copy from one SQL table to another, especially within the same database schema, than it is to bring them over from a remote Access query.  So, in short, you bring it over into a temporary place, making sure you got it all, then you swap it into the final location.

There are DBA’s that will disagree with this, and those that will agree.  I side with the latter.  So, I’ll shut up and drop the code below.  Remember: as always, this is for example only.  No garantees are given of any kind.  Be sure to modify to suit your needs and test test test test before using in any production environment.

'****************************************************************
' Filename..: access_2_sql.vbs
' Author....: David Stein
' Date......: 08/18/2009
' Purpose...: import ms-access 2007 data into a sql 2005 table
' SQL.......: (source) MS Access 2007 .accdb file
' SQL.......: (target) SERVER\INSTANCE:DatabaseName
'****************************************************************
Option Explicit

Const sourceDB    = "\\server\sharename\folder\ms_acces_data.accdb"
Const sourceTable = "qry_MyQuery"
Const targetSrv   = "SERVER2\SQL_INSTANCE"
Const targetDB    = "SQL_Database_Name"
Const tempTable   = "dbo.tbl_TempTable"
Const finalTable  = "dbo.tbl_FinalTable"

' required if using SQL security (if you use AD/Trusted, modify the dsn below)
Const dbuser = "SQL_USERNAME"
Const dbpwd  = "SQL_PASSWORD"

Const adOpenForwardOnly = 0
Const adOpenKeyset = 1
Const adOpenDynamic = 2
Const adOpenStatic = 3
Const adLockReadOnly = 1
Const adLockPessimistic = 2
Const adLockOptimistic = 3
Const adLockBatchOptimistic = 4
Const adUseServer = 2
Const adUseClient = 3
Const adCmdText = &H0001
Const adCmdTable = &H0002
Const adCmdFile = &H0100
Const adStateClosed = &H00000000
Const adStateOpen = &H00000001

Dim sourceDSN, targetDSN, conn1, cmd1, rs1, rs2, query1, conn2, icount, query

sourceDSN = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & sourceDB
targetDSN = "DRIVER=SQL Server;SERVER="&targetSrv&";database="&targetDB&";UID="&dbuser&";PWD="&dbpwd&";"

On Error Resume Next

'----------------------------------------------------------------

wscript.echo "info: processing initiated at " & Now

'----------------------------------------------------------------
' truncate destination (target) table
'----------------------------------------------------------------

wscript.echo "info: truncating table..."
Set conn2 = CreateObject("ADODB.Connection")
conn2.Open targetDSN
conn2.Execute "TRUNCATE TABLE " & tempTable & ""
conn2.Close
Set conn2 = Nothing
wscript.echo "info: table has been truncated"

'----------------------------------------------------------------
' open connection to source database
'----------------------------------------------------------------

Set conn1 = CreateObject("ADODB.Connection")
Set cmd1  = CreateObject("ADODB.Command")
Set rs1   = CreateObject("ADODB.Recordset")

query1 = "SELECT * FROM [" & sourceTable & "]"

wscript.echo "info: opening connection to source..."
wscript.echo "info: source database is " & sourceDB
wscript.echo "info: source table is " & sourceTable

conn1.Open sourceDSN

rs1.CursorLocation = adUseClient
rs1.CursorType = adOpenStatic
rs1.LockType = adLockReadOnly

Set cmd1.ActiveConnection = conn1

cmd1.CommandType = adCmdText
cmd1.CommandText = query1
rs1.Open cmd1

wscript.echo "info: sending query to source..."

If rs1.BOF And rs1.EOF Then
    rs1.Close
    conn1.Close
    Set rs1 = Nothing
    Set cmd1 = Nothing
    Set conn1 = Nothing
    wscript.echo "fail: no records found"
    wscript.quit(1)
Else
    cols = rs1.Fields.Count
    rows = rs1.RecordCount
    wscript.echo "info: " & rows & " records were returned"
End If

'----------------------------------------------------------------
' open connection to target database
'----------------------------------------------------------------
wscript.echo "info: opening connection to destination..."

Set rs2 = CreateObject("ADODB.Recordset")
On Error Resume Next

rs2.Open tempTable, targetDSN, adOpenDynamic, adLockOptimistic, adCmdTable

If err.Number <> 0 Then
    rs2.Close
    Set rs2 = Nothing
    wscript.echo "fail: unable to connect to destination..."
    wscript.echo "fail: rs2 (" & err.Number & "): " & err.Description
    err.Clear
    wscript.quit(2)
End If

'----------------------------------------------------------------
' SOURCE column names
'----------------------------------------------------------------
' EmpID
' FirstName
' LastName
' Department
' ManagerID
' Email
' WorkPhone
' HireDate
'----------------------------------------------------------------

'----------------------------------------------------------------
' DESTINATION and FINAL column names
'----------------------------------------------------------------
' emp_id
' f_name
' l_name
' dept
' mgr_id
' email
' work_phone
' hire_date
'----------------------------------------------------------------

wscript.echo "info: importing source records..."

icount = 0

Do Until rs1.EOF
    rs2.AddNew
    rs2("emp_id").value = rs1("EmpID").value
    rs2("f_name").value = rs1("FirstName").value
    rs2("l_name").value = rs1("LastName").value
    rs2("dept").value   = rs1("Department").value
    rs2("mgr_id").value = rs1("ManagerID").value
    rs2("email").value  = rs1("Email").value
    rs2("work_phone").value = rs1("WorkPhone").value
    rs2("hire_date").value  = rs1("HireDate").value
    rs2("date_added").value = Now
    rs2("comment").value = ""
    rs2.Update
    rs1.MoveNext
    icount = icount + 1
Loop

wscript.echo "info: " & icount & " records were imported"

'----------------------------------------------------------------
' close transfer connections and release objects
'----------------------------------------------------------------

rs1.Close
conn1.Close
Set rs1 = Nothing
Set cmd1 = Nothing
Set conn1 = Nothing

rs2.Close
Set rs2 = Nothing

'----------------------------------------------------------------
' truncate final table and import from temp table
'----------------------------------------------------------------

If icount > 0 Then
    wscript.echo "info: truncating final destination table for rollover..."
    Set conn2 = CreateObject("ADODB.Connection")
    conn2.Open targetDSN
    conn2.Execute "TRUNCATE TABLE " & finalTable & ""

    wscript.echo "info: table [" & finalTable & "] has been truncated"
	
    query = "INSERT INTO " & finalTable & " (" & _
    "emp_id, f_name, l_name, dept, mgr_id, email, work_phone, hire_date," & _
    "date_added, comment) " & _
    "(SELECT emp_id, f_name, l_name, dept, mgr_id, email, work_phone, " & _
    "hire_date, date_added, comment FROM " & tempTable & ")"
	
    wscript.echo "info: rolling data from temp to final..."
    conn2.Execute query, , adCmdText

    conn2.Close
    Set conn2 = Nothing
    wscript.echo "info: rollover completed"

Else
    wscript.echo "warn: no data was imported so temp was not rolled into final"
End If

'----------------------------------------------------------------

wscript.echo "info: processing completed at " & Now

Windows Server 2008, IIS, ASP, ADO and Access 2007

Ah, the joys of walking into a mine field alone. For those of you who don't know me, I've spent years writing web apps using ASP and a bit less (but way more often) on PHP+MySQL. Most of my ASP work was done using MS-SQL or Oracle, but lately these lines have blurred somewhat. I just finished up an application for a customer that uses ASP with MySQL. Talk about weird. It works fine though.

For those of you that do know me, how about a phone call once in a while? Eh? :(

So I'm building a web app to interface with Active Directory, which is a scaled down version of one I wrote for a previous employer. Instead of managing users, groups, computers, contacts and tracking all the crap that goes with that (for what else but SOX), this one is for home use. And while the big corporate-y version allowed me to control AD operations securely from my Blackberry, and provided our Deloitte and Douchebag auditors with more than enough reporting to make them grab a kleenex, I don't need that level of power at home.

I wanted to be able to empower my wife with the ability to inflict the ultimate torture on kids of cutting off their computer access. She's not up to dealing with ADUC or cryptic CMD shell commands. Scripts would be nice, but I don't want to dole out permissions like that (not that I don't trust my wife, but she might hit a malicious web site during her crazy surfing and it might leverage her elevated privs to do more damage than I would like - sorry honey). I also considered desktop shortcuts to scripts (one for each child) to stuff a record into the database or write a file to be picked up by another process, either by event sinks or by scheduling, but ah, yeck, too messy.

No, this little project will simply provide all the kids' user accounts with their ENABLED/DISABLED status and the option to toggle those individually. The site runs on ASP using IIS7 (Windows Server 2008) and only allows for toggling user accounts between the two given states. The site runs under Windows Authentication to allow my wife and I access. The toggle requests are queued in a database which is then queried on a schedule by another job that runs with elevated privs to execute the toggle requests and mark the database records as completed and timestamped. Very simple stuff - Nothing Earth-shattering here.

The challenge came with choosing a database. I thought about SQL 2005, but my AD DC server (my lone wolf) has three legs and piling another sack of goods on might break it's back. So I decided to go lightweight. I looked for SQL Express 2005. But when I get to the Microsoft site it goes right to SQL Express 2008 CTP/RC or whatever. Now is where the fun begins!

One of the pre-reqs for SQLX08 is to have .NET Framework 2.0 SP2 installed. But there is no .NET Framework 2.0 SP2. There is only .NET 2.0 SP1. The docs took me on a wild goose chase to discover a small post that .NET Framework 3.5 is supposed to rectify that, and allow a .NET 2.0 SP2 pre-req audit to pass. Not so! It does not! I have 3.5 installed and it still chokes during the SQLX install saying it needs .NET 2.0 Sp2 installed and stops there.

Frustrated, I did a Google search for SQL Express 2005 and found the download link on the Microsoft web site (funny how it still seems to be easier to find things on Microsoft's web site using Google). I installed SQLX 2005 and setup the table and permissions. I ran into so many stupid problems trying to get ASP to not only just read it (aka "SELECT"), but try to modify (aka "UPDATE") table rows. Gnashing my teeth again, I opted for MS-Access 2007.

More fun.

Google is the best. How can we live without it? I created an Access 2007 database with a table and all the required fields and datatypes, constraints, etc. Then I copied the .accdb file up to the ASP folder on my web server/domain controller/file server/print server/music and media server/foot-rest server, and linked it up to my ASP page using ADO and standard connectionless stuff. It failed with an expected 500 error. This page describes why and what to do about it.

Google led me to find the required Access Runtime Engine for MS-Access 2007. Even though there's no mention of it being required for WS08 and it's not on the system requirements list, it worked! Best of all, I didn't even have to reboot my server after installing it. And when it finished, I simply hit refresh on my ASP web page and it cranked up fine.

Now, my wife can go to our internal web site and lock the kiddies out and continue on with her chores without having to call me at work and whine about having her hands tied. I may scale this up if I have time and a need, but for now it's fine.