Jim Lawrence
accessd at shaw.ca
Mon Jan 3 16:03:59 CST 2011
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 -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Monday, January 03, 2011 1:33 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Moving to .Net (was Ded Moroz sends you ...) 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 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com