Shamil Salakhetdinov
shamil at smsconsulting.spb.ru
Fri Oct 16 08:57:25 CDT 2009
Hi John, You can use DAO in C#/VB.NET, although you can't bind forms/reports (MSReportViewerControl) to DAO recordsets therefore yes, DAO has to be removed I suppose. But if you're so "sticky" (:) kidding) to DAO you can model/simulate it via ADO.NET. It shouldn't be a big issue to create wrapper classes simulating DAO (the DAO features you use - this subset is rather limited I expect) but using ADO.NET, and then that wrapper classes can have properties, which can be bound to e.g. WinForms... WithEvents is everywhere in .NET - you'll feel OK with that. WinForms events do differ from MS Access forms' ones but you can find good equivalents I suppose. All in all I still suppose that conversion of your framework to .NET wouldn't be a complicated task - I'd propose to do that conversion not literally but conceptually - preserving your framework's principles/concepts/architecture but substituting (and not trying to simulate) technologies as DAO with the .NET native ones... I must also note that nowadays (in the near future with release of .NET Framework 4.0/VS 2010) we will get so powerful framework from MS that developing custom frameworks would become an overkill... <<< Microsoft kindly gave us the DAO object model and I know it (and program it) very well. >>> Well, DAO forced so many developers to think too straightforward navigational way, and it (DAO) was developed the time when it was already clear for many years that a one working with relational databases should better use "set thinking" approach - it was a real PITA to use DAO all that years, how many "spaghetti" code was developed because of that... In .NET as I noted already in another thread here for enterprise level apps and small businesses custom apps when programming against backend DBs are that MS Access or MS SQL ones - you usually need just a few - I'd count less than ten classes and methods of ADO.NET. Yes, I understand in your framework you make many run-time dynamic SQL-scripts generation - you will not need that in .NET - but if you'll need you can use NHibernate for dynamic objects/SQL or many code generation tools for static objects/SQL generation etc. - and I'd rely solely on ADO.NET Entity Framework starting .NET Framework v.4.0 ... 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 5:17 PM To: Discussion concerning Visual Basic and related programming issues. Subject: Re: [dba-VB] Access FE --> VB: Conversion/Rewrite Time? 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 <<< snipped >>> __________ Information from ESET NOD32 Antivirus, version of virus signature database 4514 (20091016) __________ The message was checked by ESET NOD32 Antivirus. http://www.esetnod32.ru