jwcolby
jwcolby at colbyconsulting.com
Fri Oct 16 08:16:51 CDT 2009
Shamil, My framework probably would not be trivial to port because it programs the DAO model to the metal. DAO exposes all of the MDB to the programmer and I manipulate LOTS of MDB stuff. Since you are throwing out the MDB you have to hand convert all of that code to something else. Let's take one small example. I have a framework that loads a class for a form. Each form class automatically loads a class for each control, specific to that control type. Each control class knows how to do things specific to it's ACCESS control capabilities. Text box classes do text box things, combo classes do combo things, tab control classes do tab control things. When my bound form loads, each text box control class instance drills down into it's bound field looking for the data type. To do this it uses the recordset clone and starts accessing the field collection to get its field, the properties collection of the field to get the data type. If it is a date it asks the framework for and applies a standard date format to the control. That code is DAO specific, i.e. it would have to be looked at and manually converted. That is one of about a thousand similar things that I do. Thanks entirely to you I use WithEvents extensively. I sink all of the form's events in the control class (though I don't process every single event of course). I do extensive processing in OnLoad and OnCurrent, BeforeUpdate and AfterUpdate inside of clsFrm. I have control classes for each control type and they sink and process many different text box events, combo events, button events. Are all of these events identical for VB? Is what they would do identical in VB? Is the method of turning on the event identical in VB? My framework is not a library of functions, it is an Access FE specific operating system that loads when the project loads. It loads SysVars that control every aspect of the framework operation, and allows me to selectively modify that operation on a form by form basis. It loads a form class when any form loads, the form class loads control classes for every control as the form loads. It performs standard processing automatically and programmatically. I use the double click event of a combo to load a form that exposes the list of objects in the combo, moves to the record displayed by the combo and allows the user to edit that record (or any other if they wish), refreshing the combo when the form closes. I modify the label back color to cue the user that the dbl-click works. All of that kind of functionality is embedded in the framework and I program in the form's OnLoad what form to open, what mode the form opens in etc. It takes me one line of code to program this dbl-click for a given combo on a given form. The framework uses DAO to do all of that. If you move to VB then DAO is going away right? That means manual conversion of all of that code. You assume that "existing functionality" means it loads / displays and saves data. "Power user" stuff. I assume that there are many experienced programmers out there that go waaaaaaaaaaaaaayyyyyyyy beyond Northwind. Microsoft kindly gave us the DAO object model and I know it (and program it) very well. This is one of my frustrations with the .Net system - while it can do all that and more, it does it very differently. Translating what I do now in Access to .Net is NOT a trivial task. Someday I will be able to do all of this and more in .Net but it is not a straightforward port. Every single DAO reference has to be translated. Whoever ports a complex Access application must be VERY experienced in .Net as well as Access. How many .Net programmers do you know that are VERY experienced in Access (or even want to admit it is more than a toy!)? Sounds like a niche market for us eh? ;) John W. Colby www.ColbyConsulting.com Shamil Salakhetdinov wrote: > Hi John, > > Thank you for your remark. > > 1 form/report times 2.5 works rather well provided existing functionality is > preserved. For new projects 1 (final) form/report times 4 is a better > ballpark figure. This is software development industry wide experience. It > doesn't matter what framework etc. is used. BTW, your framework could be > relatively easy ported to .NET, I suppose. > > Thank you. > > -- > Shamil > > -----Original Message----- > From: dba-vb-bounces at databaseadvisors.com > [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Friday, October 16, 2009 4:17 PM > To: Discussion concerning Visual Basic and related programming issues. > Subject: Re: [dba-VB] Access FE --> VB: Conversion/Rewrite Time? > > It also depends on many other things. For example if you were to convert > one of my projects you > would be facing my framework and tons of classes and modules. That stuff > might just convert but > maybe not. How about DAO specific code in modules? I reference databases, > recordsets, fields, even > properties of fields, I use dynamic queries modifying TDFs in code, I build > dynamic SQL and execute > it with the database object. > > I have error logging, login logging, usage of forms logging. I control > access to forms and controls > on forms based on user/group/usergroup security, manipulating Enabled, > Locked and Visible properties > based on the user rights. I control subform loading based on whether a ton > of controls two forms up > have valid data in them, allowing supervisors to override but not normal > users. > > Also what BE are you going to? SQL Server? Staying with an MDB? How about > VBA functions embedded > in queries? Are you moving from DAO bound to ADO unbound? Are you setting > a DAO recordset to the > form's recordset clone and then doing stuff behind the scenes? I am now > using pass through queries > to pull data from SQL Server views. > > How about import / export of data? My applications strip files off of email > and download from FTP > sites, and even watch directories, then convert to / from CSV and fixed > width files, importing and > exporting to tables. I have table driven code which builds fixed width > reports with header and > footer information based on mainframe specs provided by banks and insurance > companies. > > Your formula would probably work if the original was written by a power user > (or summer intern in > the case of NorthWind). I would be VERY hesitant to make a firm quote on > such a rule of thumb. > > John W. Colby > www.ColbyConsulting.com > > > Shamil Salakhetdinov wrote: >> Hello Dan, >> >> I'd count it as one form/report => 1 day => times 2.5 = that would include >> all project costs not only development. >> But if you do not plan to change any functionality then it can be done >> quicker - here is a real life conversion case's stats online: >> >> http://northwind.codeplex.com/Thread/View.aspx?ThreadId=54924 >> >> The estimations were between 45 and 165 hours - just for conversion >> development work - average estimation was exactly around the final figure: >> ~65 hours for 35 forms/reports (with subforms/sureports). Final result is >> not "industry strong" - it would need another 60 hours to make it > "industry >> strong", even more time would be needed to write docs and online help if >> needed etc. - all in all it will be 1 day for 1 form/report for such a >> simple application... >> >> Of course it also depends on how experienced your developers are, what >> architecture your converted system is planned to have etc. >> >> Thank you. >> >> -- >> Shamil > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature > database 4514 (20091016) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.esetnod32.ru > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature > database 4514 (20091016) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.esetnod32.ru > > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com > >