Microsoft Access Team Blog : Code

Running a Command as Administrator in VBA

robcooper — Wed, 11 Nov 2009 16:23:32 GMT

We received a question the other day from someone who was using the Shell function in VBA to run a command in a command prompt. The command in question was netsh dhcp, but this could apply to any number of commands.

The original code was as follows:

Shell "c:\windows\system32\cmd.exe /k netsh –c dhcp"

This code had worked for a while, but on Windows Server 2008 (and presumably Windows Vista and Windows 7), this command requires elevated permissions. There are likely a few ways to do this, but we’ll look at the runas command to make this work.

The runas command allows you to start a process as another user. For our purposes, the syntax is something like:

RUNAS /user:<UserName> program

To run netsh using the runas command, you could change the code as follows:

Shell "runas /user:administrator ""c:\windows\system32\cmd.exe /k netsh –c dhcp"""

This will launch a command window and prompt you for the administrator password in the command window itself.

Another way to do this is to use "runas" as the verb for the ShellExecute API function as follows:

Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" _
(ByVal hWnd As Long, _
   ByVal lpOperation As String, _
   ByVal lpFile As String, _
   ByVal lpParameters As String, _
   ByVal lpDirectory As String, _
   ByVal nShowCmd As Long) As Long

Sub RunAsAdmin()
Const SW_NORMAL As Long = 1

    ShellExecute hWndAccessApp(), _
                 "runas", _
                 "c:\windows\system32\cmd.exe", _
                 "/k netsh -c dhcp", _
                 "c:\windows\system32", SW_NORMAL
End Sub

When you run the RunAsAdmin procedure, you should be prompted by Windows to run the specified command.

A better way to reference tab control pages

cdowns — Fri, 06 Nov 2009 02:38:54 GMT

In VBA, a common way to refer to the pages of a tab control is to use the Value property. However, Luke Chung, President of FMS Inc., recommends using the PageIndex property instead. Click here to find out why!

Send your Power Tips to Mike and Chris at accpower@microsoft.com.

Convert hexadecimal color codes so you can use them in code

cdowns — Mon, 26 Oct 2009 15:14:08 GMT

Today's guest blogger is Michael Merlin, Lead Software Developer at Electronic Communities.

I recently wasted an hour trying to set a field's Back Color property to the hex code generated by the color picker. I figured it out after some searching, but still nobody online had the exact correct answer. I wrote a function that lets you easily use the hex color in code. The secret is to swap the R and the B, and then convert the hex to long. Further explanation follows in the comments of the function.

Cheers!
Michael

Public Function HexColor(strHex As String) As Long

    'converts Hex string to long number, for colors
    'the leading # is optional

    'example usage
    'Me.iSupplier.BackColor = HexColor("FCA951")
    'Me.iSupplier.BackColor = HexColor("#FCA951")

    'the reason for this function is to programmatically use the
    'Hex colors generated by the color picker.
    'The trick is, you need to reverse the first and last hex of the
    'R G B combination and convert to Long
    'so that if the color picker gives you this color #FCA951
    'to set this in code, we need to return CLng(&H51A9FC)
    
    Dim strColor As String
    Dim strR As String
    Dim strG As String
    Dim strB As String
    
    'strip the leading # if it exists
    If Left(strHex, 1) = "#" Then
        strHex = Right(strHex, Len(strHex) - 1)
    End If
    
    'reverse the first two and last two hex numbers of the R G B values
    strR = Left(strHex, 2)
    strG = Mid(strHex, 3, 2)
    strB = Right(strHex, 2)
    strColor = strB & strG & strR
    HexColor = CLng("&H" & strColor)

End Function

Expand only the subdatasheets you want

cdowns — Wed, 21 Oct 2009 15:43:00 GMT

Today's guest blogger is Pavlo Pedan of ARGO Business Corp. He has 15 years of experience with Access and has a great site of tips at http://sites.google.com/site/msaccesscode/.

If you have a form that contains subdatasheets, you can use the following VBA command to expand all of them:

Forms![FormName]![SubFormName].Form.SubdatasheetExpanded = True

However, we often want only some of the subdatasheets to be expanded, based on
some criteria (for example - expand only if subdatasheets contain data.)

Watch a short video demo and download a demo database from this page. Make sure you have added a reference to the "Accessibility" library (%windir%\system32\oleacc.dll).

This has been tested on Access 2007.

Send your Power Tips to Mike and Chris at accpower@microsoft.com.

Nulls vs. zero-length strings: a Power Tip from the past

cdowns — Wed, 14 Oct 2009 18:48:12 GMT

Today's guest blogger is Access MVP Garry Robinson, who offers the Smart Access collection of articles at http://www.vb123.com/kb.

A few months ago I purchased the rights to publish the Smart Access magazine online and it is from that collection that I offer this tip from Paul Litwin, the first editor of Smart Access. At the end of that I provide a link to an editorial on Null Values written by the second editor Peter Vogel. It never hurts to get a refresher course on Null values, a necessary evil for database developers.

Tip by Paul Litwin from 1997

Even though Access considers Nulls and zero-length strings (ZLS) separate values, often developers wish to treat them as equivalent for the sake of an If...Then statement or some other stretch of code. One way to accomplish this is to write code like this:

' Not so efficient 
If IsNull(varAge) or varAge = "" Then
     ' do something 
End If

A better way to do this is:

' More efficient 
If Len(varAge & "") = 0 Then
     ' do something 
End If

This second version of the code is more efficient for two reasons. First, if varAge is Null, the code converts it into a ZLS by appending a ZLS to it. This lets us replace two tests with one. Second, it’s simply more efficient to check for a ZLS using Len(ZLS) = 0 rather than ZLS="".

You can use a variation of this technique if you ever need to place the value of a text box or a variant variable into a string. Strings can’t contain Null values, so you may be tempted to write code like this that first checks to see if the text box is Null:

' Another correct but slow method 
If IsNull(txtAge) Then
     strAge = "" 
Else     
     strAge = txtAge 
End If

A much faster way to do this is to use code like this instead:

' This is faster 
strAge = txtAge & ""

This code avoids doing the test altogether by setting the value to the concatenation of the text box and a ZLS. If the text box is Null, this converts it into a ZLS. If the text box is either a ZLS or a regular value, then the concatenation has no effect.

Read more on Nulls in Peter Vogels editorial here http://www.vb123.com/kb/200207_pv_ed.htm

3 new articles available on MSDN

cdowns — Mon, 05 Oct 2009 18:40:46 GMT

MSDN writer Sal Ricciardi alerted us to the availability of 3 new articles on MSDN, two written by Luke Chung of FMS Inc., and one co-written by Luke Chung and Dan Haught.

Title	Author(s)
Performance Tips To Speed Up Your Access 2007 Database	Luke Chung and Dan Haught
Error Handling and Debugging Tips for Access 2007, VB, and VBA	Luke Chung
Tips and Techniques for Queries in Access 2007	Luke Chung

Definitely bookmark these for future reference!

Send your Power Tips to Mike and Chris at accpower@microsoft.com.

Dynamically Resize a Subform Based on the Record Count

Mike Stowe — Wed, 30 Sep 2009 23:53:05 GMT

Today’s guest blogger is Vinny Malanga. Vinny is the CTO of IMI Software, Inc. , which specializes in software development for the real estate and property management industries.

Many Access developers implement subforms to display data. Most often, at design time, the developer sets the subform to a specific size. In many cases this is fine, but there are some instances where it would be preferable to dynamically resize the subform at runtime, based on the number of records that it contains, up to a maximum number. Once the maximum number of records is reached, a vertical scroll bar should appear allowing the user to scroll through the rest of the records. The maximum number is arbitrary and simply used to prevent the subform from exceeding a certain height.

I’ve provided a sample database that you can download here. The database contains a table, two forms - a parent form and a subform - and a module with the resize method.

In short, when the parent form loads, it calls a function on the subform which handles the resizing. It first retrieves the height of the header, footer and detail section of the subform. From there the subform is resized based on the height of the header, the height of the footer, and the height of the detail times the number of records. There are a couple of twips added to the total number to even out the border around the subform. Next, the record count of the underlying data source is retrieved. If the record count is greater than the maximum number of records you’ve defined, the ScrollBars property of the subform is set to 2 (Vertical Only), otherwise 0 or None. Lastly, in case there are any controls that exist under the subform, another function is called which repositions those controls based on the calculated height of the subform.

I hope some of you find this technique useful.

Tracing Function Calls in VBA

Mike Stowe — Thu, 24 Sep 2009 20:36:33 GMT

Today’s guest blogger is Joel Graff. Joel is a field engineer with the Illinois Department of Transportation (IDOT).

Often, I find when looking for the source of an error in VBA code, a function call trace which returns the path of function calls preceding the error to be invaluable. While more complete compilers provide this feature as a part of the IDE, it is, unfortunately, absent in VBA. To accommodate this, I’ve written my own function call stack classes to help me trace errors. This implementation is based on something I found online, though I have since lost the reference. I cannot give credit where credit is due, only note that the basic implementation is at least somewhat borrowed.

There are two classes I use: cErrStack and cErr.

cErrStack – Instanced as a global object, this provides the stack for procedure names as they are called. Procedures are added / removed (pushed / popped) from the stack as they come in and go out of scope. When an error occurs, the stack then contains, in order, the procedures called up to the procedure in which the error occurred. The cErrStack object returns the procedure name in which the error occurred and the trace path of function calls preceding the error with the methods ErrorProcedure() and Trace(). For higher-level error handling (where error handling occurs at the form level or only in main procedures), the ErrorProcedure() and Trace() routines will not provide correct information. In these cases, ErrorProcedureHistory() and TraceHistory() should be used instead.

cErr – Instanced at the procedure level, this object pushes the name of the procedure on the global error stack object (the cErrStack object). When the procedure terminates, the cErr object goes out of scope, triggering its Terminate() Event. This event then removes (pops) the terminating procedure’s name from the global error stack.

A sample error message may look like this:

Often, when I deploy a new database that hasn’t had all the bugs worked out, I write my error handling routine to automatically open an email and paste the above information into it. That way, users can send me the relevant error information automatically. I also use line numbers to help better identify problem code, though I didn’t implement them in this example.

The original implementation only allowed for trace information to be available in the procedure in which the error occurred. That is, if an error occurred in a function with no error handling, then by the time the error was passed back to the procedure which did handle it, the stack would no longer have accurate trace information. However, as one Access user pointed out to me, adding error trapping code to every function creates a lot of code bloat and isn’t really necessary. Better code practices suggest use of “high-level” error trapping – trapping in main functions or at the form level. To accommodate “high-level” error trapping, I added a second stack to the cErrStack class, which contains a “trace history”.

The idea is simple: When an error occurs in a function with no handling, the error is passed up the line until it is handled. That means that once an error occurs in higher level error handling, a “history” needs to be preserved until the error is handled. The class object does this by copying the contents of the immediate stack to the history stack when a “pop” occurs, and simply reassigning the history stack to the immediate stack when a “push” occurs. Thus, when an error occurs and is passed up the line to the handling procedure (a series of “pops” occur on the immediate stack), the history stack is preserved. Once a push occurs on the immediate stack (which presumably won’t happen until after the error is handled) the history stack is destroyed and referenced to the immediate stack.

Attached is a sample of how the application works. There are three scenarios. The first two (“Lefthand Error” and “Righthand Error”) are “immediate” error handling examples. The last one is a high-level error handling example.

Click the icon below to download the sample classes.

Send your Power Tips to Mike and Chris at accpower@microsoft.com.

Switch the Property Sheet on and off from VBA

cdowns — Wed, 23 Sep 2009 22:17:31 GMT

Today's guest blogger is Pavlo Pedan of ARGO Business Corp. He has 15 years of experience with Access and has a great site of tips at http://sites.google.com/site/msaccesscode/.

When you open a form or report in Design View, the Property Sheet is either displayed or hidden based on its state the last time you left Design view. However, you might want to ensure that the Property Sheet is always displayed (or hidden) when you switch to Design view. You might think to use the following command:

DoCmd.RunCommand acCmdProperties

Unfortunately, this command only works after the form or report is already open in Design View. To ensure that the Property Sheet is always displayed or hidden when you switch to Design view, use the function below. The function can be executed while starting an application (for example in the AutoExec macro), attached to the Close event of the form or report, or whenever necessary.

For example, you might use the function to suppress the blinking of the Property Sheet when creating a form at a run-time using the Application.CreateForm method and opening it in a Form view.

Here's the code, which has been tested in Access 2007.

'----------------------------------------------------------------
' Module    : modSwitchPropertySheet
' Author    : Pavlo Pedan
' Date      : 31/07/2009
' Purpose   : DoCmd.RunCommand acCmdProperties only toggles Property Sheet in
'           : Form/Report Design View on/off. Use function below to turn it
'           : on or off
'----------------------------------------------------------------

Option Compare Database

Private Declare Function FindWindowEx Lib "User32" Alias "FindWindowExA" _
    (ByVal hwndParent As Long, ByVal hwndChildAfter As Long, _
     ByVal lpszClass As String, ByVal lpszWindow As String) As Long

Private Declare Function GetWindowRect Lib "User32" (ByVal hWnd As Long, _
    lpRect As RECT) As Long

Private Type RECT
    Left As Long
    Top As Long
    Right As Long
    Bottom As Long
End Type

Function fSwitchPropertySheet(blnON As Boolean) As Boolean
'----------------------------------------------------------------
' Procedure : fSwitchPropertySheet
' Author    : Pavlo Pedan
' Date      : 31/07/2009
' Purpose   : switch Property Sheet in Design View (blnON = False to turn off)
'----------------------------------------------------------------

    Dim frm As Form
    Dim hWnd As Long
    Dim rectControl As RECT

    ' create temp form
    Set frm = CreateForm

    ' find handle for Property Sheet window
    hWnd = FindWindowEx(Application.hWndAccessApp, 0, "MsoCommandBarDock", _
        "MsoDockRight")
    If hWnd > 0 Then

        ' get coordinates of the window
        GetWindowRect hWnd, rectControl
        ' determine action
        If blnON Then
            ' if window width is 0, switch it ON
            If rectControl.Left = rectControl.Right Then
                DoCmd.RunCommand acCmdProperties

                'returns True if action made
                fSwitchPropertySheet = True
            End If
        Else
            ' if window width is not 0, switch it OFF
            If rectControl.Left <> rectControl.Right Then
                DoCmd.RunCommand acCmdProperties

                'returns True if action made
                fSwitchPropertySheet = True
            End If
        End If

    End If

    ' close temp form without saving
    DoCmd.Close , , acSaveNo

End Function

Send your Power Tips to Mike and Chris at accpower@microsoft.com.

Using VBA to Send Data to a Table from an Unbound Form Control

Mike Stowe — Wed, 16 Sep 2009 21:27:22 GMT

Today’s guest author is Justin Farrell, author of the Access 2007 tutorial http://www.dealing-with-data.net.

This is a useful trick which gives the Access Developer additional flexibility when working with forms and data. It uses Access VBA and DAO.

Once the user enters data into the unbound textbox (txtBox) and clicks the Send Data To Table button, Access opens a recordset based on the tblTest table. The txtBox data is then stored in a variable called varTextData and then added to the rst recordset. The recordset is updated and the txtBox control is reset ready for new data to be entered. The result is an unbound form that interacts with a database table.

Private Sub cmdSend_Click()

Dim db As DAO.Database
Dim rst As DAO.Recordset
Dim varTextData As String

    varTextData = txtBox

    Set db = CurrentDb
    Set rst = db.OpenRecordset("tblTest", dbOpenDynaset)

    rst.AddNew
    rst!fldTest = varTextData
    rst.Update
    rst.Close

    db.Close
    Me!txtBox = ""
End Sub

Justin’s supplied a sample database that illustrates this technique.

Send your Power Tips to Mike & Chris at accpower@microsoft.com.

"Convert" a TextBox to a ComboBox at a run-time

cdowns — Mon, 14 Sep 2009 20:27:48 GMT

Today's guest blogger is Pavlo Pedan of ARGO Business Corp. He has 15 years of experience with Access and has a great site of tips at http://sites.google.com/site/msaccesscode/.

Some people do not like having ComboBoxes on a form because of drop-down buttons. Microsoft offers a solution here, but this approach does not work for a datasheet view – the drop-down button shows up when the ComboBox gets the focus.

Some people do not like ComboBoxes because the control requires some time to be populated from its row source. The row source could be remote and/or could be based on complex calculations. On the other hand, we actually need selection features of ComboBox only while editing respective field. Often we do not need all
this overhead while simply navigating through records (unless we want to see data from a different column of the ComboBox).

While a ComboBox can be populated dynamically while entering symbols (see this great article from Allen Browne), the other approach is to get rid of the ComboBox itself while just displaying records and get it involved only when necessary.

Please have a look at my short video demo and download the VirtualComboBoxDemo sample database here.

When left-clicked or Alt+Down is pressed, a pop-up non-modal form that contains only one ComboBox shows up exactly over the TextBox. The text part (with or without a dropdown button) can be hidden or made visible, and can be made to use the AutoCorrect feature or not (see the code for details). This approach works for both Form and Datasheet views. Not much VBA programming is required. The ComboBox "converts" back to a TextBox if you press ESC, Tab or Shift+Tab, or when you click somewhere on a main form. This emulates natural ComboBox behaviour.

So now we have a form with TextBoxes only! When we need ComboBox, it appears on-the-fly and disappears when we are done with selection. This has been tested with Access 2007.

The usage of the clsControlLayout class is explained here.

Send your Power Tips to Mike and Chris at accpower@microsoft.com.

Return a Limited Number of Rows on a Criteria Form

Mike Stowe — Thu, 16 Jul 2009 09:29:00 GMT

Today’s guest blogger is Alison Balter. Alison is the founder of InfoTech Services Group, Inc. and has authored 14 Access books since 1995.

When working in a client/server environment, it is imperative that you limit the number of rows that the user brings over the network wire. It is therefore necessary that you supply a criteria form that allows the user to specify the rows that they want to return. The problem is that the user often designates criteria that is way too broad. In that situation, you must determine that there is a problem, and require the user to create criteria that returns less rows. An example is the form shown below.

As you can see, the user first selects from a Search For combo box to designate the field within they wish to search. They then determine whether they are looking for the criteria as an exact match, starts with, or whether the search string is contained within the field. If the user enters criteria that returns over 500 rows, the message box below appears.

The user must narrow their criteria and try again. The exception to this is if the field being searched is either the Vendor Used Cage Code or the Requested Cage Code. In that case the message shown below appears, and only the top 500 rows appear.

The code below accomplishes all of the functionality described above.

Private Sub SearchProjects()    Dim strFieldToSearch As String    Dim strValueToSearch As String    Dim strOperatorToSearch As String    Dim strWhereClause As String    Dim strWhereClauseSQL As String    Dim strWhereClause_Acct As String    Dim strWhereClauseSQL_Acct As String        'Declare recordset used to hold the count of rows returned from the server    Dim rst As ADODB.Recordset    Dim lngRowCount As Long        strFieldToSearch = Me.cboSearchFor.Value    strValueToSearch = Me.txtFindItem    strOperatorToSearch = Me.cboSearchWithText.Value        'Evaluate whether the user has selected Starts With, Exact Match, or Contains    Select Case strOperatorToSearch        Case "S"   'Starts With            strWhereClause = strFieldToSearch & " Like '" & _                strValueToSearch & "*'"            strWhereClauseSQL = strFieldToSearch & " Like '" & _                strValueToSearch & "%'"        Case "E"   'Exact Match            strWhereClause = strFieldToSearch & " = '" & _                strValueToSearch & "'"            strWhereClauseSQL = strFieldToSearch & " = '" & _                strValueToSearch & "'"        Case "A"   'Contains            strWhereClause = strFieldToSearch & " Like '*" & _                strValueToSearch & "*'"            strWhereClauseSQL = strFieldToSearch & " Like '%" & _                strValueToSearch & "%'"    End Select        Set rst = New ADODB.Recordset    rst.ActiveConnection = CurrentProject.Connection        'Open the recordset, returning the count of ProjectID    'from vwSearchRequisitions based on the criteria the user has designated    rst.Open "SELECT COUNT(ProjectID_Projects) AS NumRows " & _        "FROM vwSearchRequisitions WHERE " & strWhereClauseSQL        lngRowCount = rst!NumRows        rst.Close        'If the count returned from the server is less than or equal to 500,    'all is well, and the data is displayed in the appropriate subforms    If lngRowCount <= 500 Then            Me.fsubSearchRequisitions.Form.RecordSource = _            "SELECT * FROM vwSearchRequisitions WHERE " & _            strWhereClause & " ORDER BY EnteredOn DESC"        Me.fsubSearchRequisitions.Form.Requery        Me.fsubSearchRFQ.Form.RecordSource = _            "SELECT * FROM vwSearchRequisitions WHERE (" & _            strWhereClause & ") AND ProjectID_RFQ IS NOT NULL" & _            " ORDER BY EnteredOn DESC"        Me.fsubSearchRFQ.Form.Requery        Me.fsubSearchBid.Form.RecordSource = _            "SELECT * FROM vwSearchRequisitions WHERE (" & _            strWhereClause & ") AND ProjectID_BID IS NOT NULL" & _            " ORDER BY EnteredOn DESC"        Me.fsubSearchBid.Form.Requery        Me.fsubSearchAcct.Form.RecordSource = _            "SELECT * FROM vwSearchRequisitions WHERE (" & _            strWhereClause & ") AND ProjectID_Acct IS NOT NULL" & _            " ORDER BY EnteredOn DESC"        Me.fsubSearchAcct.Form.Requery    Else        'If the search returned more than 500 rows, but the user is searching for        'Vendor Used Cage Code or Requested Cage Code, return the top 500 rows.        If Me.cboSearchFor.Column(0) = "Vendor Used Cage Code" Or _            Me.cboSearchFor.Column(0) = "Requested Cage Code" Then            MsgBox "Data Being Reduced to 500 Most Recent Rows", _                vbInformation, "Warning"            Me.fsubSearchAcct.Form.RecordSource = _                "SELECT TOP 500 EnteredOn, ProjectID_Projects, " & _                    "ExpiresOn, ProsIDNum, " & _                    "SnapReqID, GeneralReqID, CustFileNum, ReqCageCode " & _                    "ReqVendor, PNNum, NSN, Qty, UOM, PartDesc, " & _                    "GROUP BY EnteredOn, ProjectID_Projects, " & _                    "ExpiresOn, ProsIDNum, " & _                    "SnapReqID, GeneralReqID, CustFileNum, ReqCageCode " & _                    "ReqVendor, PNNum, NSN, Qty, UOM, PartDesc, " & _                    "HAVING (" & strWhereClause & _                    ") AND ProjectID_Acct IS NOT NULL ORDER BY EnteredOn DESC "        Else            'For any other field display a message that the criteria must be narrowed            MsgBox "Your Criteria is Returning Too Many Rows. " & _                    "Narrow Your Criteria and Try Again", vbExclamation, _                    "Please Try Again"            Exit Sub        End If    End IfEnd Sub

The code first determines whether the user has selected Starts With, Exact Match, or Contains. Note that regardless of their choice, the code sets the value of two variables: strWhereClause and strWhereClauseSQL. It must do this because the SELECT COUNT is executed on the server. SQL Server does not understand the asterisk (*). It is therefore necessary to create a variable with the percent (%) sign, the wildcard in SQL Server.

Now the code is ready to open the recordset, returning the count into lngRowCount. Next the code evaluates lngRowCount. If it is less than or equal to 500, all is well, and the data is displayed in a datasheet. The data is based on a vwSearchRequisitions with the appropriate WHERE clause applied (based on the selected criteria).

If the search returned more than 500 rows, but the field being searched was either Vendor Used Cage Code or Requested Cage Code, a message box appears warning the user that only the top 500 rows will appear in the datasheet, and then SELECT TOP 500 is used to return the appropriate rows.

Finally, if the user is searching any other field, and the number of rows returned is greater than or equal to 500, a message appears, and the search is aborted.

Case-Sensitive string comparisons

cdowns — Fri, 26 Jun 2009 19:56:24 GMT

Today’s guest blogger is Michael Groh, co-author of the popular Access 2007 Bible.

The VBA language is not, by default, case-sensitive. A statement such as

CBool("XYZ" = "xyz")

will always return True. You might come across this issue in cases such as the following:

If strOne = strTwo Then

' Perform some operation here

End If

Consider what happens if it's important to know that the strings differ only by case. By default, VBA will never report a difference in the strings based only on the case applied to the string variables.

One easy fix is to use the InStrB ("in string byte") function, which considers the strings based on byte value (where "x" is different than "X"). By contrast, the InStr function considers just character value ("x" is the same as "X").

The transformed If statement becomes:

If CBool(InStrB(strOne, strTwo)) Then...

This statement takes the output of InStrB() and converting it to a Boolean (True or False) expression. When InStrB returns 0 (no match found), CBool converts the expression's value to False. If InStrB finds the strings match (by case and by character) the expression evaluates to True.

You'll find that using the InStrB() function is much faster and easier than writing a VBA function that parses each string and does a binary or ASCII comparison on each character in both strings.

Get your favorite Power Tip on the blog! Send it to Mike and Chris at accpower@microsoft.com.

Counting the days…

cdowns — Wed, 10 Jun 2009 07:38:43 GMT

Sal Ricciardi of the Access Developer Documentation team has produced a couple of articles for MSDN that address two commonly-asked date-related questions about Access:

Using Excel Date Functions in Access 2007 shows how to use Excel’s NETWORKDAYS function from within Access.
Counting the Number of Working Days in Access 2007 describes how you can create the Weekdays and Workdays user-defined functions to count the number of working days between two dates.

Thanks Sal!

Sample Class Eases Creation of Similar Forms

Mike Stowe — Sat, 06 Jun 2009 01:40:58 GMT

Last week Joel Graff shared his story on how he used Access to track salt usage for the Illinois Department of Transportation. Some of you wanted to know more about the custom class that he uses to ease the creation of similar forms.

Joel has agreed to share a sample implementation of his custom class.

It basically uses three interrelated lookup tables to demonstrate the class with varying degrees of complexity (three different examples). I made use of the nifty article on writing help using reports to provide some information on how it performs. I’m no guru at interfaces / tutorial writing, but hopefully what I’ve sent is a sufficient example.

I suppose it's homebrewed enough anyone who knows better would get a chuckle or two off of it, but I'd love to see what someone else thinks.

You can download Joel’s sample database here.