IN this installment of Access Answers, I m answering

Transcription

1 Subforms to Security Access Answers Smart Access Christopher Weber This month, Christopher Weber runs through questions that range from subforms to transparently joining secured workgroups. IN this installment of Access Answers, I m answering questions about subforms that won t stay in sync, filtering through a many-to-many relationship, and letting your users apply custom numbering to their reports. I ll also offer a way to easily switch workgroups and launch secured apps. I have a one-to-many relationship that I d like to show using a main form/subform interface. However, there s too much information in the subform to show on our 800x600 monitors unless we scroll across a 14-inch subform. Instead, I d like to have general information from the child record in a subform on the left (subform A), and specifics about the same record in a linked subform on the right (subform B). I ve synchronized the forms using subform A s OnCurrent event to requery subform B (subform B uses a parameter query for its RecordSource that refers to key values in a control on subform A). I think I m doing everything right, but when subform A first opens, it can t requery subform B because subform B hasn t opened yet. I tried using On Error Resume Next to override the error, but now subform B complains that it can t find the parameter control on subform A. This is driving me crazy! This is a tricky one because you ve run into an error that Access might or might not consistently raise. Let s examine the problem with an example that reflects your situation. I ve used the Northwind database to create frmcustomermain with two subforms that show general and shipping information about each customer s Orders (suborders on the left and subordersshippinginfo on the right, as shown in Figure 1). Everything fits nicely on the screen, even at 800x600. I synchronize my subforms by using a parameter that references the OrderID field in subordersshippinginfo s query, just as you did: OrderID=[Forms]![frmCustomersMain]! _ [suborders].[form]![txtorderid] As you stated, subordersshippinginfo must be updated (requeried) each time suborders record changes, and, as in your example, I accomplish this in suborders OnCurrent event. I use the Me.Parent property to avoid having to spell out the main form s name: Private Sub Form_Current() Me.Parent!subOrdersShippingInfo.Form.Requery End Sub But, when I open my form, I get a non-specific object reference error (see Figure 2, on page 19). Access can t find subordersshippinginfo the first time suborders OnCurrent event fires. This is because it hasn t yet opened the related subform. At this point, I suspect that everyone is tempted to use On Error Resume Next to plow over this error in the OnCurrent event. After all, the error should only occur the first time the subforms open. After that, the two forms should find each other. If you do go ahead and add the Resume Next statement, things might work just fine... Figure 1. A set of interconnected subforms. 18 Smart Access August 2001

2 or they might not! It all depends upon which subform Access decides to open first. I ve yet to figure out how Access decides which it will open first, but, should it happen to open the dependent subform (subordersshippinginfo) first, you ll get a parameter window looking for the linking control on the first subform (suborders) like the message in Figure 3. Worse than that, Access might not prompt you, and just open up the form blank. Try figuring that one out... The first time I got the blank form situation, I reopened and closed my form and made seemingly random changes until finally the parameter prompt showed up. Then, I realized that Access had somehow changed the order in which it was opening my subforms. Herein lies the crux of the problem. You need to control which subform opens first. In our example, we need suborders to open before subordersshippinginfo. The solution is actually deceivingly simple: Don t set the SourceObject property of the dependent subform (subordersshippinginfo). Instead, set it dynamically in the first subform s Open event. Here s suborders event handler: Private Sub Form_Open(Cancel As Integer) Me.Parent!subOrdersShippingInfo.SourceObject = _ "fsubordersshippinginfo" End Sub Now, everything happens in the correct sequence: 1. suborders opens. 2. The code in suborders Open event sets the SourceObject property for subordersshippinginfo. 3. This causes subordersshippinginfo to load and fire its query. 4. subordersshippinginfo finds suborders already open and retrieves its parameter. 5. Subsequent movements on suborders requery subordersshippinginfo. All is well. And you won t need to use On Error Resume Next. My users have a form that lists some products and orders. They d like the ability to filter Orders that have one or more of the selected Products in their details. They also want the ability to find Orders that include all (not just one or more) of the selected Products in their details. I can give them a list box of available Products, but I can t seem to figure out the two filters. Your question strikes at the heart of the problem: What does each filter look like? Here, you re trying to filter a parent table (Orders) where it shares common information with a sibling table (Products) through a linking child table (Order Details). In both cases, the filter needs to use subqueries in its SELECT statements. As in my previous answer, I ll use the Northwind database to demonstrate my solution. In the first instance, to view all Orders that may have any of the desired Products (1, 12, 13, or 24) in their details, I d create the following query: SELECT Orders.* FROM Orders WHERE OrderID IN WHERE ProductID IN(1, 12, 13, 24)) The subquery returns [Order Detail].OrderIDs, which are linked to one (or more) of the ProductIDs found in the IN(1, 12, 13, 24) list. The outer SELECT statement then returns Order.OrderIDs, which are found in the list of OrderIDs returned by the nested sub-select statement. To derive the filter, simply extract the WHERE clause without the word WHERE, leaving: OrderID IN WHERE ProductID IN(1, 12, 13, 24)) In the second case, things are a bit more complicated. To return Orders where the corresponding Order Details include all of the selected ProductIDs, you have to use multiple subqueries in your SELECT statement. For example, to view all OrderIDs that have both ProductIDs 2 and 16 in their details, I d create subqueries that are coupled together with the AND operator: SELECT OrderID FROM Orders WHERE (OrderID In WHERE ProductID =2)) And (OrderID In WHERE ProductID =16)) Figure 2. The error message from querying a form that isn t yet opened. Figure 3. The dialog box that indicates a missing parameter. Smart Access August

3 Here, each subquery filters the OrderIDs against the selected ProductIDs one at a time. Because the subqueries are coupled by AND operators, the resulting set of OrderIDs is pared down to just those associated with all of the selected Products. Again, the filter is derived from the WHERE clause without the word WHERE : (OrderID In WHERE ProductID =2)) And (OrderID In WHERE ProductID =16)) This filter might be a bit more tedious to string together, but it s a powerful enhancement for your end users. The code to create the list of ProductIDs for both filters is easily implemented with a multi-select list box of ProductIDs/Product Names on a dialog form called by a button on your form. Once your user selects the desired Products from the list, use a For Each loop to iterate through the list box s ItemsSelected collection. For the any case, place each item in a comma-separated list between the parentheses in the filter s ProductID IN() list and apply the filter. For the all case, place each within a separate subquery statement that s coupled to the previous one with the AND operator. I ve created an example using the Northwind Orders form in the database that s available in the Source Code file at Just click the Filter by Products button to see it work (try searching for both Chang and Chai). I have a report that needs a custom numbering scheme based upon user input. I know how to use a text box with a Running Sum, but this solution necessitates my user getting at the report s design view to set the initial number. Is there a workaround? The Running Sum report technique is certainly a handy item to have in your toolkit. In the usual case, you simply set the control source to the starting number and set the Running Sum property to Over Group or Over All to have numbered reports. However, this solution only works by setting the number in design view. You might be tempted, as I was, to use a report s ability to accept parameters, as shown in Figure 4. Unfortunately, starting at any number other than 1 causes the Running Sum to add that same value each time the control is printed. So, if you enter, say, 101, the control will print 101, 202, 303, and so forth. The real solution is actually similar to this, but it requires that you manage the number to be added for each printing of the control through a VBA function. Here s my function GetNext(), which accepts two long parameters: lngstart (the place to start) and lngincrement (the number to add). The function returns the new value: Function GetNext(lngStart As Long, _ Optional lngincrement As Long = 1) As Long Static lngcurrent As Long If lngcurrent Then lngcurrent = lngcurrent + lngincrement Else lngcurrent = lngstart End If GetNext = lngcurrent End Function Now, to supply the starting number and the value to increment by, you call the function from your text box s Control Source, supplying both the function s arguments through a pair of report parameters (see Figure 5 to see how to set the Control Source parameter). Note that I m not using the Running Sum property. In my code, the static variable lngcurrent retains the value from previous calls and increments each subsequent call by lngincrement. I ve also made lngincrement an Optional parameter with a default value of 1. This way, you can just prompt your users for the starting value and let the function automatically increment by 1. The If statement in the code checks to see whether lngcurrent is set to a value. If it isn t, it means that this is the first call to the routine and the return value is just lngstart. Every other time the routine is called, the return value is the value from the last call plus lngincrement. One last point, and a very important one at that: Be sure to put this function in the report s class module. This way, the static lngcurrent will be destroyed when the report closes. If you put the function in a public module, subsequent calls to it by any report during that session of Access will pick up the last value of lngcurrent, and your users will have their reports start counting Figure 4. Accepting parameters in a report s property. Figure 5. Using the GetNext function in a report. 20 Smart Access August 2001

4 where the last report left off. My users find it a pain in the neck to work with secured databases that are governed by separate departments using different workgroup files. Is there any way to alleviate the tedium of joining different workgroups? To work in a secured MS Access database, your users must first join the workgroup that governs the database and then launch MS Access to open the target MDB file. This is because users and security groups contained within the workgroup object are given permissions on individual objects within the databases governed by the workgroup. Though object permissions are stored in the containing database, they re only recognized when compared to the security identifier (SID) of an individual user or member of a secured group, and those SIDs are contained in the governing workgroup. Thus, whenever Access is launched through a secured workgroup, it prompts you for your user name and password to verify your existence in the users collection and determine your permissions on objects within the target database. There are two major annoyances with this implementation. First, for one of your users to log in to a machine that s already using the application, the running instance of Access on that machine must be terminated so that it s not left exposed. The user must then restart Access and log in to become the current user. Secondly, once a secured workgroup is joined on that machine, Access will continue to prompt your users each time they launch Access, regardless of whether or not they re accessing a secured database. To avoid the login process for unsecured databases, your user needs to rejoin an unsecured workgroup. Likewise, if the users want to work in a second database that s governed by another workgroup, they must once again exit Access, join the governing workgroup, and then open the secured database. These travails can be minimized using a free download, the Secured MDB Launcher. Joining a workgroup through the MS Access Workgroup Administrator (WrkgAdm.exe) simply changes a Registry entry that Access checks when the application is loaded. To simplify using a secured workgroup, a small launcher applet can read and store the Registry entry for the current (default) workgroup, change the value of the key to point to the secured one specified for the target database, open the target database, and then reset the Registry key to its original value. That s how the Secured MDB Launcher works. When you execute the Secured MDB Launcher applet for a secured MDB file, it gleans all of this information from an INI file found within the same directory as a copy of the applet. The software reads the Registry key specified in the INI file for the current version of MS Access and stores the value (the name and path of the current workgroup file) for reuse. It then reads the name and path of the target secured workgroup from the INI file, and changes the specified Registry key to the name and path of the target secured workgroup file. The Secured MDB Launcher then reads the name and path of your target MDB database file from the INI file and launches an instance of MS Access using that file. Lastly, it rewrites the Registry key with the name and path of the previously specified workgroup file, leaving it in the state in which it was originally found. The next time your users open Access, they re using their original workgroup file and never need to open the workgroup Administrator again. Here s a portion of the self-documenting INI file that accompanies each copy of the Secured MDB Launcher used to open a secured Access database: This Secured MDB Launcher applet sets the MS Access workgroup file (MDW) to that specified by name and path in the TargetWorkgroup setting within this INI file. Thus, the user of Access on this machine has joined the specified workgroup. It then launches the Access database (a secured MDB file) specified by name and path in the TargetMDB setting within this INI file using the workgroup specified. It then resets the workgroup Registry setting to its original value allowing users of Access on this machine to subsequently open unsecured MDB files without logging in. The Registry key to change is specified Smart Access August

5 in the WorkgroupKey setting within this INI file and can be changed for different versions of MS Access. For example, the setting for Access 97 would be: \SOFTWARE\Microsoft\Office\8.0\Access\ Jet\3.5\Engines\ while the setting for Access 2000 would be: \SOFTWARE\Microsoft\Office\9.0\Access\ Jet\4.0\Engines\ [WorkgroupKey] WorkgroupKey=\SOFTWARE\Microsoft\Office\8.0\ Access\Jet\3.5\Engines\ [TargetWorkgroup] TargetWorkgroup=C:\MyPath\MySecuredWorkgroup.mdw [TargetMDB] TargetMDB=C:\MyPath\MySecuredDatabase.mdb Once you ve created an INI file with the appropriate setting for your version of Access along with the paths to your Workgroup and database, you re all set. Your users just have to open each secured database through the appropriate icon that actually runs a copy of the Secured MDB Launcher (SecuredMDBLauncher.exe) on its accompanying INI file (MDBInfo.INI found in the same directory). Once you ve set your users up with the appropriate shortcuts, each having an appropriate name and icon, you ll wonder how you ever got along without the launcher. The Secured MDB Launcher was conceived by Dennis Ward and myself, and written by Jamie Grant at the DSW Group, Ltd. It s a small footprint Delphi executable, free for download at SA0108AA.ZIP at Christopher Weber travels throughout the country teaching Access development and programming seminars for The DSW Group in Atlanta. He s been an Access developer since its first release, enjoys working with clients, and heads The DSW Group s Access development and training team. cweber@thedswgroup.com. Know a clever shortcut? Have an idea for an article for Smart Access? See the back page for the contact information where you can send your ideas. ADO.NET... Continued from page 11 exciting new visual programming features that address all of the problems that Visual Basic 6 developers encountered with the infamous DataEnvironment. I ve even avoided talking about Typed DataSets, which exploit.net s inheritance features to allow you to create DataSets with additional methods and properties to add custom functionality. I ve avoided doing all these things because I wanted to establish the fact that, despite initial appearances, ADO.NET really has built on the best features of classic ADO. These have been re-structured to make the two different processing models (server-side and client-side/ disconnected) clearer and easier to use. These changes have also repositioned ADO not only to support standard desktop and client/server applications, but also to serve the steadily increasing demand for highly scalable, Webfriendly data access. Rob MacDonald is an independent software specialist based in England. He provides training and consulting services to clients around the globe, specializing in.net, COM+, and data access as seen from VB. Rob s latest book, Serious ADO, is published by Apress. He s also the author of many articles and manages the VB.NET training curriculum for the Visual Basic User Group. In his dreams, he has a pet weasel called Eric. rob@salterton.com. 22 Smart Access August 2001