Jim Lawrence
accessd at shaw.ca
Wed Jul 13 11:16:39 CDT 2005
Hi John: The methods I have used were designed about eight years ago and have copied/improved again and again. Here are the basics and a step by step methodology: 1. I always use ADO-OLE. (One exception is MySQL... a bit of a pain. If someone could figure out a method that would not require a station by station visit to install the MySQL ODBC drivers I would be for ever indebted.) 2. The forms and subforms are populated as the user moves through the records and but until the user actually changes field content on a form or attempts to delete the current record, the recordset used to feed the form is static. 3. a) A record or group of records in the case of a subform being displayed, are first pulled into a recordset, and content are then used to populate the form collection. In theory the record exists in three places. b) If there is a change of deletion request the recordset is locked by creating a dynamic recordset with record-lock attribute. c) If an 'already locked' error occurs when this lock is being applied then the user is informed of the condition and given the appropriate options. d) When using a 'real' :-) SQL DB (MS SQL/Oracle etc.) much of the record handling is managed internally as soon as the 'BeginTrans' is applied and closed or resolved when the 'CommitTrans' or 'RollbackTrans' runs. It may initially seem a little complex but it gives a full range of options for managing the data and it allows the client to build large databases with many users and only requires the purchase a few licenses/seats. (ie. 20 licenses and 100 users.) Using ADO makes is easy to switch or attach different data sources with little effort. (In theory one line of code.) Even web applications can be created leveraging the same methods. That is not totally true but given that SQL versions are standardizing coupled with the use of Store Procedures/Queries, with passing parameters, very few changes are needed. I am still pacing around the XML pool but believe in the long run that is where to go. So there is the 'thumb-nail' sketch of the 'non-bounder' application implementation methodology. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby Sent: Wednesday, July 13, 2005 4:35 AM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Framework book - was caption from code Jim, My framework (the part that had to do with forms and controls) was indeed aimed at bound forms. However the concept works for unbound forms as well. Indeed it would be even more critical to use a framework as you the developer are doing so much of the work that Access was doing for you - loading all of the data into the controls, checking for updates to the data by other people before you wrote changes back to the table, writing the data back from controls into fields in the tables, stuff like that. All of that code would be framework material. Once written and stored in the framework, the doing of it would be automatic by the framework. If you are one of the unholy (unbounders) why don't you give a thumbnail sketch of how you manage all of that work. I will then brainstorm how I would look at doing it in a framework. Remember that the concept of a framework is to make it as automatic as possible. For example (in a bound form) I have a form class and I have a class for each control type. The form class runs a control scanner, gets the control type of each control, loads a class instance for each control found. Once this is done, the form class and control classes can work together to do tasks. As an example, I can literally just drop a pair of controls on the form, a text box named RecID that exposes (is bound to) the PK (always an autonumber) and an unbound combo called RecSel. The names are specific and if the control scanner finds this pair of controls it knows that a record selector exists and runs the code. The afterupdate of the combo by that name calls a method of the parent form saying "move to recid XXXX". The column 0 of the combo is the PK of the record in the form so it knows the PK. The form's OnCurrent knows that it needs to keep the combo synced to the displayed record in the form so it calls a method of the combo class telling it to display the data relevant to the current record in the form. Thus the form, the combo and a text box all work as a system to form a record selector. If the developer drops these two controls on the form he "just has" a record selector. Nothing else is required - other than binding RecSel to the PK field and setting the combo's query to display the data and get the PK of the records in the table. As an unbounder, you need to think about how to achieve this kind of "automaticness" in the things you do. Naturally some tasks do require feeding data into init() methods of classes to set the classes up to do their job. After that though the "systems" need to just work together. Load the data into the unbound form / controls. Store flags in each control's class saying that control's data was modified. Scan for all controls with modified data and update the underlying data in the record. Check for data changes in the data you are about to update and inform the user that another user edited the record since you loaded the data. Etc. John W. Colby www.ColbyConsulting.com Contribute your unused CPU cycles to a good cause: http://folding.stanford.edu/ -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Wednesday, July 13, 2005 2:29 AM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Framework book - was caption from code Hi John: Save a copy for me. It sounds like a good read...but I guess it only works with bound forms.(?) Jim -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com