THERE have been a number of articles in Smart Access

Size: px

Start display at page:

Download "THERE have been a number of articles in Smart Access"

Barry Parker
5 years ago
Views:

1 Prometheus Unbound Smart Access David Moss If you re thinking of moving to a client/sever database, you can do it in Access. However, if you re going to get the performance that you need, then you ll need to change the way that you do things. David Moss shows how to replace the built-in functionality with some reusable code. THERE have been a number of articles in Smart Access over the past two years about the issues raised by moving Jet applications to a client/server architecture. Clearly, we re all doing it. The primary issue is that, in a high-volume, multi-user client/server system, you re not going to use bound forms. You have to use unbound forms to avoid flooding the network with huge recordsets and to give the database engine some chance of managing record locks. Without bound forms, there are many built-in facilities of Access that you can t use instead, you ll have to write your own. To prevent rewriting that code for each project, you ll need some standard routines to handle these activities. I ve created a maintenance toolbar, shown in Figure 1, that replaces this functionality. I add this toolbar to my forms (renaming it each time). This article will show you what routines that toolbar should have, discuss some of the pitfalls, and share with you some of the opportunities that become available. You might find it useful to re-read the article Client/Server Development with Access by Mary Chipman and Mike Gunderloy in the August 1999 issue of Smart Access. Where that article outlines the techniques required, this article will show you some of the code. Some developers use SQL Server as their back end, some use DB2, and others use Oracle. The examples in this article are based on an Oracle back end. Some Oracle-specific features will necessarily intrude, but my intention is to concentrate on the Access end and techniques that are Figure 1. A standard toolbar for unbound forms in a client/server application. common to all client/server applications (see the sidebar Data Access Methods for a discussion of understanding the different data access methods). Getting the data If your forms are unbound (that is to say, you don t set the RecordSource property), then there s no data for Access to retrieve when the user opens the form. To overcome this, the Open event of each of my forms has code like this: Private Sub Form_Open(Cancel As Integer) On Error GoTo Form_Open_Err iinitialise "Open" Set oamaintform = Me Set oamaintdynaset = oauser.dbcreatedynaset( _ "select * from cacauses", &O0) oamaintopeningsql = oamaintdynaset.sql oamaintreportname = "rptcauses" oamaintreportquery = "qrycauses" oamaintreportsql = "select * from cacauses " oamaintreportkey = "cacause" Form_Open_Err: ierror "Causes", "Form_Open" End Sub In this code, I set the values of the variables oamaintform, oamaintdynaset, and so on, that are used by standard code. The oamaintreport* variables are all used by the ireport method, called from the maintenance toolbar to produce reports based on the form specified in oamaintform. DbCreateDynaset is a method of OO4O, the data access method I m using to connect Access to the Oracle back-end database. You could substitute ADO, RDO, ADO, or even ADO.NET. OO4O includes an OraDynaset object (oamaintdynaset), which has an SQL property, an Updatable property, a Fields collection, and a DbRefresh method among others. If you ve worked with any set of Data Access Methods You need to choose carefully how to connect Access to your back-end database manager. I ve chosen Oracle Objects for OLE (OO4O) as my data access method. You may choose something else. How do you choose? I recommend Oracle Programming with Visual Basic by Nick Snowdon (Sybex, 1999). I found that it helped me to untangle the alphabet spaghetti of ADO, DAO, ODBCDirect, OO4O, and RDO. It could prove useful to you even if you don t use Oracle as a back end. 14 Smart Access October 2001

2 data access object, the point of these properties is probably obvious. ierror is a standard procedure of mine that s used to display errors raised by Access or Oracle or both. I ll discuss iinitialise later in this article. To get back to the point, in the Form_Open procedure it s the method that retrieves the data and moves it to the form. The routine looks like this: Sub () If oamaintopeningsql = "" Then On Error GoTo _Err For Each oamaintfield In oamaintdynaset.fields If IsNull(oaMaintField.Value) Then oamaintform(oamaintfield.name) = "" oamaintform(oamaintfield.name) = _ oamaintfield.value If oamaintfield.oraidatatype = 2 Then oamaintform(oamaintfield.name) = _ Val(oaMaintForm(oaMaintField.Name)) Next oamaintfield On Error Resume Next oamaintform.icurrent 'default to no edit oamaintform.allowedits = False _Err: 'problem getting LONG data without RowId If Left(Err.Description, 9) = "OIP-04131" Then Resume Next ierror "Maintenance", "" End Sub Typically, I call from many procedures, and there might or might not be anything to display. So the first thing the code does is check to see whether there s a control on the form for each field in the dynaset. For this to work, the ControlName for each field must be the same as the FieldName in the recordset (which must be the same as the column name in the underlying table). If you don t want every field to display on the form, you must still provide a control, but you can set their Visible property to False. For each field, I extract the fieldname and data type. One of the Oracle numeric data types is stored as text, so my code converts it back to a number. In a databound form, the OnCurrent event is where you ll put much of your data-handling code. The OnCurrent event will never be raised by an unbound form. I add an icurrent procedure to my forms and call that from my method. I also set the form s AllowEdits property to False and require users to press the Edit button on the toolbar, which allows edits. By the way, only supports a single form view of the data. Navigation If your forms are unbound, then you can t use the Access navigation facilities and will have to write your own First Record, Next Record, Previous Record, Last Record, GoTo Record#, and AddNew procedures. My maintenance toolbar includes all of these functions. The iaddnew method, for example, looks like this: Public Function iaddnew() On Error GoTo iaddnew_err If iclean() Then iclear oamaintform.allowedits = True oamaintaddnew = True iaddnew_err: ierror "Maintenance", "iaddnew" My iclean routine, which is called from this code, checks to see whether any of the controls on the form have different values from the underlying recordset if so, they ve been updated, and the user is offered the chance to save the new values before navigating to a new row. My iclear method sets the value of each control on the form to a zero-length string. oamaintaddnew is a property of the maintenance object and is required by my isave method, which decides whether to create an SQL Update or Insert command based on this flag. Saving data My isave method is called by the Save button on the maintenance toolbar. For integrity reasons, all code within isave is run inside a transaction. The Access BeforeUpdate event will never be raised by an unbound form and so isave executes ibeforeupdate, which may optionally be included in the given oamaintform. Some dynasets are updatable, in which case isave calls the isaveupdatable routine, and others are not, in which case my code calls the isavenonupdatable routine. These both execute optional iafterupdate and iafterinsert procedures in the given oamaintform. isaveupdatable simply uses the DbUpdate method of the Oracle dynaset: Public Function isaveupdatable(bcancel As Boolean, _ bmsgbox As Boolean) Dim baddnew As Boolean Dim strmessage As String On Error GoTo isaveupdatable_err If oamaintaddnew Then baddnew = True oamaintaddnew = False oamaintcheck = False oamaintdynaset.dbaddnew baddnew = False oamaintdynaset.dbedit For Each oamaintfield In oamaintdynaset.fields If IsNull(oaMaintForm(oaMaintField.Name)) Or _ oamaintform(oamaintfield.name) = "" Then oamaintfield.value = Null oamaintfield.value = _ oamaintform(oamaintfield.name) Next oamaintfield oamaintdynaset.dbupdate If bmsgbox Then MsgBox "Data saved" Smart Access October

3 On Error Resume Next oamaintform.iafterupdate bcancel If bcancel Then If baddnew Then oamaintform.iafterinsert bcancel isaveupdatable_err: bcancel = True strmessage = "" If oauser.lastservererr = 2291 Then strmessage = _ "Data you have amended contravenes the " & _ "relationships between tables." & vbcrlf & _ "For example, you may have entered " & _ "a property reference number for a " & vbcrlf & _ "job and there is no such number on " & _ "the properties master table." ierror "Maintenance", "isaveupdatable",,, _ strmessage One difference between Jet applications and working with a server database is that, however complicated the JOIN in the underlying SQL statement, it s usually possible to create an updatable recordset with Jet/DAO. If all else fails, you can set the RecordsetType to Dynaset (Inconsistent Updates). There are, however, more constraints on updatability when it comes to SQL Server, DB2, and Oracle. In this environment, you ll encounter many more non-updatable recordsets (typically, views) that aren t susceptible to DbUpdate. Since it can t update through the recordset, my isavenonupdatable has to execute SQL Update or Insert statements against the underlying tables. The code then refreshes the dynaset using the DbRefresh method to rebuild the dataset to reflect the new data. The question arises: Is there any way in your code to know which table to manipulate? You know the field in the dynaset that s changed, but which of the n tables in the view did it come from? There s nothing (that I can find) in the Oracle data dictionary that identifies the source table of a column in a view. The only solution is to enforce strict naming conventions so that you can identify the source table from the fieldname (for example, all names with a prefix ca denote columns from the cacauses table). It s not very elegant, but that s the way it is. As with most refresh-like methods, Oracle s DbRefresh positions the cursor back at the first row of the dynaset. As a result, isavenonupdatable has additional code, not found in isaveupdatable, that navigates back to the row in the dynaset that was current when the user clicked on the Save button (and which is still displayed on the screen). Close iclose is a method of the maintenance object called by the Close button on the maintenance toolbar: Public Function iclose() Dim bcancel As Boolean If iclean() Then Err.Clear On Error Resume Next bcancel = False oamaintform.ibeforeclose bcancel If Not bcancel Then DoCmd.Close acform, oamaintform.name iinitialise "Close" One of the benefits of this technique is that it allows you to fill a hole in the Access event model. There s no BeforeClose event in the Access event model, but now you can add one here yourself. Simply declare an ibeforeclose routine in your code that accepts a single Boolean variable, and my routine will call it before closing. This allows the close action in my maintenance object to be canceled, unlike the Access Close event. To cancel the close in your ibeforeclose routine, set the parameter to True. When it comes to reports, the RecordSource has to be set to a pass-through query. One point to note here Access doesn t like subreports (or subforms) to be sourced from pass-through queries. The solution is to write your pass-through query and then write a non-pass-through query that selects data from the pass-through query and set the RecordSource of the subreport to the non-passthrough query. Sort Your forms are unbound, so you can t use the sort ascending and sort descending buttons provided by Access. This code replaces the Access routine: Public Function idescending() On Error GoTo idescendingerr oamaintorder = oamaintform.activecontrol. _ Properties("Name") & " DESC" If IsNumeric(Len( _ oamaintform.activecontrol.controlsource)) Then " ORDER BY " & oamaintorder If Not oaqbefilter = "" Then If InStr(oaMaintOpeningSQL, "where") = 0 Then " WHERE " & oaqbefilter & " ORDER BY " & _ oamaintorder " AND " & oaqbefilter & " ORDER BY " _ & oamaintorder DoCmd.Hourglass True oamaintdynaset.refresh DoCmd.Hourglass False oamaintorder = "" idescendingerr: MsgBox "You must select a control on the form "& _ "in order to sort the rows", vbexclamation The iorderascending and iorderdescending methods need to preserve the filter, if any, already 16 Smart Access October 2001

4 specified by the user and stored in oaqbefilter, a property of the maintenance object. QBE If your forms are unbound, then you can t use the Access filter by form and filter by selection facilities. You have to code your own. My ifilterbyselection is a fairly simple procedure that uses the oaqbefilter property of the maintenance object. ifilterbyselection needs to preserve the record order, if any, that s already been specified by the user and stored in oamaintorder, another property of the maintenance object. ifilterbyform, which allows the user to enter criteria in a form to filter records, by contrast, requires a lot more work on the part of the developer. You need to create a new form that s a copy of the original form using Access s CopyObject. Users can enter criteria on this form. You need to do this the first time the facility is used and then again if the controls have changed. Similarly, you need to create an Access table to hold the separate criteria that need to be ORed together. You need an iapplyfilter method to parse the criteria entered to create oaqbefilter, but this is just a SQL WHERE clause. Really, ifilterbyform is an application in its own right. In each case, you need to provide yourself with an iremovefilter method: two oamaintforms and two oamaintdynasets, but you won t have two instances of the oamaint* variables. One solution would be to move the code into a Class module and create an object. Another solution, and the one that I implemented, is to create a stack. The stack is implemented as a set of dynamic arrays: oastackform(), oastackdynaset(), and so on. Each time a form is opened, iopen pushes an entry onto the stack, and each time a form is closed my iinitialise routine pops the entry off the stack. My ipush and ipop routines use a lot of ReDim Preserve statements to resize these arrays. Note that ipop allows the developer to pass the focus back to the right form (SelectObject). Left to its own devices, if you re not using modal forms, when you close a form in Access the focus can go back to the database window or to your opening splash form instead of the previous form. Looking back As you can see, there s a lot of work to do when you move from the Access/Jet fileserver architecture to client/server. This article has set out most of the facilities that you ll need for file maintenance. It also probably reminded you just how much work Access has been doing for you in the past. The good news is that it s feasible (I ve done it), you should only have to do it once, it opens up new possibilities for the event model, and it solves the volume, performance, and multi-user problems posed by Public Function iremovefilter() oamaintdynaset.sql = oamaintopeningsql oamaintdynaset.refresh oamaintorder = "" oaqbefilter = "" 'display values Stack You ll also have to code your own ifind and ifindnext facilities and call them from the maintenance toolbar. These routines are more critical in client/server applications than they are in Jet applications. Suppose that the user is maintaining an orders table, adding an order for a customer, and needs to look up the customer ID. You re not going to have a combo box on the orders form sourced from the entire customers table not if it s got 80,000 rows on it and it s stored in a different tablespace on a different continent. Instead, you re going to open the customers maintenance form, look up the customer using ifind, and double-click their ID back into the orders form. This can create problems. My code is kept in a module called Maintenance consisting of a lot of procedures like iclean and iclear, plus a lot of global variables like oamaintform and oamaintdynaset. So, in the preceding situation, two forms are open for maintenance simultaneously and you need Smart Access October

5 big client/server applications. It would be a good thing to have a single object that handled all of this for us. I produced something like this maintenance object back in 1988 when I was a Clipper programmer and moved it successfully from application to application for years. That is, until Access 1 came along and did all of the work for me, at least for fileserver applications. Then my applications got bigger, and I had to reinvent my object. The code in this article is the fruit of that work. You should find it as useful as I have. David Moss is the proprietor of Business Consultancy Services Ltd. and designs, develops, and implements commercial database systems. dm@buscon.demon.co.uk. Remote Queries... Continued from page 13 can also be run on FoxPro, Excel, dbase, and other databases. Unfortunately, the documentation gave little information as to how this might actually be achieved. In one application that I ve deployed, I need to occasionally retrieve data from a spreadsheet. The following query retrieves data from sheet1 of an Excel spreadsheet that s been set up as a database table: SELECT [Sheet1$].* FROM [Sheet1$] IN 'G:\Claims97\FAI\Fai_Loader.xls '[Excel 8.0;]; This has proved really useful as the database administrator involved has been trained to use the Linked Table Add-In. If I added a link to the spreadsheet, the utility would stop working when it hit the link. Even if Remote Queries aren t your cup of tea, I recommend that you take a look at the ReplaceQuery and SysTables functions that I ve included in the sample databases. They re good universal pieces of code that I ve used in a number of applications. I m continually finding reasons to use Remote Queries in my software development. They re simple to set up and maintain in software, and they allow me to continue to use the Linked Table Add-In for my normal linked tables. While I don t recommend that you convert your databases from linking technology to Remote Queries, this is useful technology to have in your knowledge bank. Also, the technology has been around and works very well in both Access 97 and 2000 with no conversion issues. REMOTEQ.ZIP at Garry Robinson is the founder of GR-FX Pty Limited, a company based in Sydney, Australia. If you want to keep up to date with the his latest postings on Access Issues, visit his company s Web site at or sign up for his Access newsletter by sending a blank to tips@gr-fx.com. If you like the approach Garry took in this article, why not try out the new version of Graf-FX, which uses Remote Queries to graph data from any remote table or query? When Garry isn t sitting at a keyboard, he can be found playing golf or exploring the remote National Parks that surround Sydney , garry@gr-fx.com. Further Reading and Resources Here are three resources where you can find more information: Open the Access Help and contents file and choose Index. Enter IN Clause to find some useful examples. Smart Access extra issue 2.13 (June 20, 2001) had a piece on Linking With Passwords that will provide you with some interesting information on passwords and linking. Archives of past issues of the enewsletter are available at In the November 1998 of Smart Access, I wrote an article, Adding Database Tools To Excel Spreadsheets, which described some of the good and bad things about linking to Excel spreadsheets. 18 Smart Access October 2001

A Back-End Link Checker for Your Access Database

A Back-End Link Checker for Your Access Database A Back-End for Your Access Database Published: 30 September 2018 Author: Martin Green Screenshots: Access 2016, Windows 10 For Access Versions: 2007, 2010, 2013, 2016 Working with Split Databases When