[AccessD] Move to C# - last post

jwcolby jwcolby at colbyconsulting.com
Mon Jan 3 17:39:53 CST 2011


Jim,

 > You noted three excellent classes you created for your client. If you were to accurately the 
hours required to get these classes fully tested and operational; what would that be? This is just a 
diabolic curiosity but do not hesitate to put an appropriate dollar value to your time with this 
development. ;-)

I cannot accurately estimate the actual time simply because I did it piecemeal, and in a waterfall 
kind of way.  IOW I started with existing SQL stored procedures (about 50 or so).  I wrote code that 
simply encapsulated calls to those plus logging.

I then went back and wrote classes that encapsulated those encapsulated stored procedures 
(supervisors if you will).

I then learned new things and... I went from a simple status text box on a form to a status list 
class which I now use throughout the system to report status for any process that needs to do so... 
and nLog, and...

I started with single threaded, then moved to multi-threaded, breaking it out etc etc.

How long would it take me to write the same from scratch knowing what I know now?

Maybe 200 hours, and I charge $60 / hour to this client.  And while that sounds like a lot of time 
and money (and it is) it automates a very complex process that moves me from 16-24 man hours per 
list (of my time) to zero man hours (of my time).  And I have a half dozen lists, and they each need 
to be processed monthly.  And my orders pass through this process as well.

So the program now saves me well over 100 man hours a month of my time.

My server still takes man days to complete the work but it no longer requires me typing on the 
keyboard for each step.

This export / process / import process is central to the business for this client.  I started 
learning C# in Sept 2009, and within two months started building the first iteration of this 
automation.  By January I was successfully processing these stored procedures and logging results. 
However it was in a sequential fashion, start one and go until it was complete.  Since any given 
table can be a couple of hundred thousand up to a hundred million records, processing a single table 
could take days of processing time.  Each two million record chunk takes about one hour to process. 
  And I had to manually start each table that needed processing.

Now I have a record in a supervisor table that contains the database name / view name of the data to 
process and the date to start the process.  The asynchronous process can read that supervisor record 
and decide whether it is time to process.  When it is, the program can do the complete thing without 
intervention.  When it is finished, if it is a data database (master data) it will automatically 
copy the supervisor record into a new record and set the date out 30 days so that it just 
automatically reprocesses every month.  If it is an order supervisor record, it just processes once 
and is done.

I have been through about three distinct refactorings to get from the first fairly clumsy stab at 
this to where I am now.  I have learned a ton along the way.  And each refactoring paid for itself 
directly as each version took less and less of my time.

John W. Colby
www.ColbyConsulting.com

On 1/3/2011 5:03 PM, Jim Lawrence wrote:
> Hi John:
>
> I agree with you fully. I have no intension of wasting any more time with MS
> Access...it is simply a dead and dying platform. :-(
>
> Getting up to speed will take a long while but I know that can not be
> helped. Any adventure into this area will cost myself dearly in time and my
> client's dearly in money but that can not be helped.
>
> You noted three excellent classes you created for your client. If you were
> to acurrately the hours required to get these classes fully tested and
> operational; what would that be? This is just a diabolic curiousity but do
> not hestitate to put an appropriate dollar value to your time with this
> development. ;-)
>
> Jim



More information about the AccessD mailing list