[AccessD] Moving to .Net (was Ded Moroz sends you ...)

jwcolby jwcolby at colbyconsulting.com
Mon Jan 3 15:32:58 CST 2011


Jim,

 > I think the main reason for the issues with the major migration to .Net is that many here have 
hundreds of thousands of field-tested lines of code tied up in VB/Access and now have to throw out 
about twenty years of work, to start again from scratch.

Uhh, yep.

More than the code, it is throwing away 20 years of knowledge about a very complex RAD environment 
(Microsoft Access).  And relearning a brand new set of knowledge.

I am there, I have that knowledge and entire frameworks of stuff that I use in Access, which simply 
does not port to .Net.

OTOH .Net can easily do things that VBA simply cannot do, and will never be able to do, things which 
I need to be able to do.

I have a system of three classes which watches for work to be done, work orders stored in a pair of 
tables in SQL Server.  Using SQL Server automation Stage1 exports 2 million record chunks into CSV 
files, until as many files are created as are required to process a table of N records (tens of 
millions of records).

Another class independently and asynchronously watches these same pair of tables for records created 
by Stage1 and when the files appear, copies them over to an input directory in a virtual machine and 
watches for files to appear in the output directory.  this class updates these same order records 
saying that the files have been processed, and also copies the records back from the virtual machine 
to a staging directory on my server.

Another class watches these same two tables and when it detects that there are files back from the 
virtual machine to be processed, imports the records back into SQL Server/

Each of these three classes uses threads, each operates entirely asynchronously from the others. 
Each updates its own status list on a tab of a form.  Each updates the pair of tables in SQL Server 
such that the other processes can know when they have to do things.

The three classes taken together perform an extremely complex set of tasks which I used to have to 
perform manually.  I tried to get the processes done synchronously using Access and even that was 
almost impossible.  With one thread to do everything, the main form would lock up as SQL Server was 
processing an ADO command etc.  It just sucked.

.Net makes it easy, although not trivial to do such things.  It is still a programming effort but it 
is doable, and when broken down into logical classes with each class having its own thread, it is 
even pretty easy.

So yea, moving away from Access is sometimes painful, but for some tasks it just makes the 
impossible possible.

I am a programmer, and I ended up in Access because in 2002 it was way powerful.  Remember the . 
language of dBase?  Access was one of the first visual dev environments and I could get stuff done 
quickly (still can).  But I am now at the point where Access is not moving forward, it has 
limitations which are never going to be addressed (though it has stellar tool bars now!!!) and as a 
programmer I just look at walking through the rest of my life in handcuffs and leg irons placed on 
me by Access.

Yea, it is taking some time to get up to speed in .Net, but .Net is by far the most powerful 
programming environment I have *ever* experienced, and it just keeps getting better.

Does that sound like Access to you?

 > I think the main reason for the issues with the major migration to .Net is that many here have 
hundreds of thousands of field-tested lines of code tied up in VB/Access and now have to throw out 
about twenty years of work, to start again from scratch.

Bitch at Microsoft for their decision to not improve the platform.  They are plainly telling you to 
move to .Net.

So I am.  I cannot fight this battle anymore.

John W. Colby
www.ColbyConsulting.com

On 1/3/2011 3:36 PM, Jim Lawrence wrote:
> Hi Shamil:
>
> I think the main reason for the issues with the major migration to .Net is
> that many here have hundreds of thousands of field-tested lines of code tied
> up in VB/Access and now have to throw out about twenty years of work, to
> start again from scratch.
>
> The nearest analogy I can come up with is like having your home destroyed by
> war and then while in your late forties, fifties or even sixties and having
> to build another life and future from scratch.
>
> It may have to be done but not everyone is happy about it.
>
> Jim



More information about the AccessD mailing list