Microsoft Access

Access 2010 hands-on-lab is available on Channel 9

Clint Covington — Tue, 09 Feb 2010 05:49:05 GMT

For all those that want to experience development with Access 2010, a new Access 2010 unit has been added to the Channel 9 Learning Center for Office 2010.

The new Building Solutions with Access 2010 Lab consists of 5 exercises highlighting the new web database feature and touches on the new Macro Designer and Data Macros. The new Macro Designer provides developers with a much easier and efficient environment to work in and Data Macros are similar to triggers in SQL Server. Rather than embed business logic throughout forms, one can associate Data Macros with tables so that anytime a user updates a table, the business logic executes at the appropriate time. And web databases, via Access Services in SharePoint 2010, can be published to the web whether the SharePoint site is on premises or hosted. The lab exercises step you through the process of building a web compatible database. If you have a SharePoint 2010 site, you can publish to it. Otherwise, you can take advantage of a free trial offer and publish your web database to accesshosting.com.

The hands-on lab exercises are:

Exercise 1: Modifying the table structure of a web database
Exercise 2: Modifying a web form
Exercise 3: Creating a new web database form
Exercise 4: Creating a database macro
Exercise 5: Publish a database to the web

Enjoy!

Access 2010: Performance improvements against SharePoint lists

Clint Covington — Fri, 05 Feb 2010 21:27:54 GMT

Today’s guest writer is DJ Cole from the Access development team. DJ is the architect and primary developer of SharePoint connectivity performance improvements.

The Access Show Overview

Our goal for Access 2010 was to make connections to SharePoint lists nearly as fast as local tables. We had to ensure requests didn’t swamp the server, bottleneck over the network, or cause the client machine’s CPU or RAM to thrash. We found caching data in local tables provided the best user experience while being conservative with resources on the server, network and local machine. Access 2010 performance improvement builds upon the Access 2007 architecture. In order to fully understand the implications to your apps, it helps to understand how Access 2007 works against SharePoint.

Improvements in Access 2007

As described in a previous blog post, the team has worked to improve SharePoint performance for some time. Back in Access 2007, there were three major changes:

Asynchronous fetches of data from the server to allow some scenarios to immediately show data before the complete recordset is returned from the server.
Fetch incremental data changes to a list within an Access session. Once the app fetches data subsequent requests, only query what has changed in the list.
Cache lists in the local database as XML.

Asynchronous fetching

When data is loaded into a datasheet or form, often just the first page of data or a single record is needed to begin working or scrolling through records. To speed up these scenarios, control is returned to Access as soon as the first batch of data has been retrieved from the server. A background thread continues parsing and fetching the remaining data from the server, blocking only when the requested record is not yet available (for example, if you press Move Last immediately after open). While this works for some scenarios, queries with joins, sorts and filters require all of the data upfront.

Fetch incremental data changes

While data needs to be fetched from the server when a link is first used within a session of Access, changes to the web service infrastructure enabled fetching incremental data changes. Access 2007 caches the data rowsets in memory after they are first opened, so subsequent usage of the SharePoint links becomes significantly faster. In cases of large datasets, there is contention for RAM on the client machine. In this case, rowsets are released, freeing RAM back to the rest of the system.

Cache lists in XML

In addition to the in-memory caching, there are options to cache the XML within the database using either offline mode or cached mode. This helps in cases where the rowsets were recycled out of memory or when using the links in a new session of Access, as some of the server calls and network time were eliminated.

Generally speaking, Access 2007 performance was much improved from Access 2003; however, it quickly slowed when users connected to lists with more than 5,000 records. The primary bottleneck was the resources required to parse and load the XML data. We had an explicit goal to support much larger datasets with Access 2010.

Improvements in Access 2010

Just like Access 2007, Access 2010 connects to SharePoint lists via web services over HTTP. When a user opens a query, form or report that consumes data from a SharePoint link, web service requests are made to the SharePoint server to get the list data. The server returns the data in XML which is parsed and cached in local tables. Lastly, the data is fetched by the Access data engine and displayed to the user.

There are three areas of improvement where Access 2010 delivers a better user experience:

Cache data in local tables,
Improve bulk query operations, and
Reduce web service calls.

Cache data in local tables

Access 2010 enhances the connected SharePoint list experience by caching data in local tables which are persisted across Access sessions. This enables Access to parse the bulk of the SharePoint XML data only once. Subsequent use of the links just fetches incremental data changes from the server. An additional benefit of using local tables internally rather than the in-memory rowsets is that usage of multi-valued lookups and value lists in a SharePoint list becomes much faster.

The first time a link is opened, Access still has to download all of the data from SharePoint and parse it into the local tables. In a situation where all of the data is needed immediately, whether from opening and moving last in the datasheet or executing a query with a join, the time to use the data is about the same as in Access 2007.

The real time savings happens the next time the link is used, either after starting a new session of Access or when many SharePoint links are used within a session. The performance for even a 50,000 row list is nearly comparable to a local table and significantly faster than the same scenario in Access 2007.

The additional benefit of the locally cached table is the memory footprint is radically reduced.

Using Access 2010 Cached Mode

The new cached mode is turned on by default for all new ACCDBs and published applications. Existing ACCDBs can use the new cached mode by checking the following box available through File -> Options -> Current Database:

This mode should not be selected if that database will be shared with Access 2007 users, though it can be used in a copy of the database that will be shared.

Bulk query operations

When exporting data to SharePoint, changes are typically sent up in batches of 50 records at a time. Access 2010 extends this batching to bulk queries against SharePoint lists, bringing the time to update 100 rows from 30 seconds to less than 3.

Reduce web service calls

During the course of developing Access 2010, multiple customers came to Microsoft and tried the new experience with cached mode. In one case, a customer had a complicated form with many sub-forms and tabs that referenced nine different SharePoint links. Previously, opening the form took over a minute, but the time decreased to less than 20 seconds when opened in cached mode. We analyzed the web service calls being made when opening the form and made changes to ensure each use of a SharePoint link on open required only one web service call. This decreased the time to open the form from 20 to 4 seconds.

What’s next?

While Access 2010 delivers significant improvements, performance work is never done! The size of the lists used is constantly growing. Users may connect to SharePoint servers located across the country or on another continent. As a result, there are more opportunities to investigate how to use the cached data more efficiently and further reduce the web service calls.

Take the new bits for spin—you can download the beta and try it against Access Hosting today. We would love to get feedback from you about your scenarios and the improvements you see.

Spend the day with an Access engineer

Clint Covington — Wed, 03 Feb 2010 18:53:55 GMT

Attention Puget Sound readers!

We are polishing Access 2010 for RTM and need your feedback. Next week a handful of Access engineers will be available to visit on-site to help customers upgrade their Access applications to Access 2010. This is your opportunity to verify your app works great with Access 2010 and to provide early feedback for our planning process.

If you are in the Puget Sound area and are interested in spending a day or two with an Access engineer, send us email. Tell us about your professional background, the business purpose of your application, and some details about your app. There are limited opportunities to participate in this project. Respond quickly and we’ll be in touch.

Access blog goes to China

Clint Covington — Tue, 02 Feb 2010 09:13:00 GMT

Lois Wang, a program manager on the team responsible for reports, has started the Access China blog. Lois will blog about Access and open a broader dialog with Access developers in China. If you read Chinese—check it out.

Friends in China—enjoy!

The Access Show: Classified ads demo

Clint Covington — Mon, 01 Feb 2010 16:51:32 GMT

Microsoft has an internal classified ads Web site that allows employees to buy and sell stuff—think of it as a company Craigslist. Barath Balasubramanian a tester on the Access team decided to recreate the app using Access 2010. I asked Barath to join us on The Access Show for a short demo. He plans to share it on Office Online once we ship Access 2010 (it will automatically show up inside the Access’ BackStage New page). In the meantime Barath has shared a beta copy on UtterAccess.

Subscribe to The Access Show: RSS, iPod/MP4, WMV (high quality), Zune, MP3

Hopefully, it inspires some of you with new ideas for the contest.

Access 2010: How to write expressions for Web queries, forms, and reports

Clint Covington — Wed, 27 Jan 2010 04:55:05 GMT

Today’s guest author is Russell Sinclair, the Program Manager for expressions, ACE, along with other features.

Access has traditionally supported a wide variety of expressions in different areas of the application. Tables and fields, queries, form and report properties, controls, and macros can all use expressions to evaluate data or logic to drive the behavior of an application. In the past, each of these contexts in which an expression is used have shared a single, common expression evaluation engine. This means that no matter where you use an expression, the functions and operators available to you will likely be the same. Things will change when you start to build web databases with Access 2010.

The architecture and access to data is fundamentally different when an application is running in a three tier environment. Control references, expressions and logic in the browser might have to make AJAX callbacks to a Web front-end, which calls a middle tier data cache, which then pulls data out of a backend server. The end result is logic in a form is constrained from utilizing optimizations inherent in the desktop version of Access. This new topology introduces changes to expressions and how they operate within Access and Access Services.

When an application is published to the server, expressions could be evaluated in JavaScript, the Excel calculation service, or using SQL Server, depending upon the context. You will find that many of the shortcuts you are used to using in client applications are not available in web databases.

Contexts

The expressions that can be used in web databases are dependent upon the context in which you are working. In all cases, the expressions available in web databases do not match the full suite of expressions that you can use in client objects. The following is a list of the main contexts in web databases, from least restrictive (the most expressions available) to most restrictive (the least number of expressions available).

Reports: This context covers all properties of reports and controls on reports that you can define in the report designer.
Queries: This context includes all expressions in queries you create in the query designer in Access. This includes stored database queries, record sources for forms, reports, combo and list boxes, as well as the macro action arguments:

In (in ForEachRecord and LookupRecord),
Where Condition (in ForEachRecord, LookupRecord, OpenForm, OpenReport, BrowseTo and SetFilter) and
Order By (in SetOrderBy).

Data Macros: This context covers the expressions that you can use in the arguments of macro actions in the logic designer (except as noted in Queries).
Tables: This context covers expressions in calculated columns, validation rules and default values.
Forms and UI Macros: This context covers expressions used in form properties, form control properties and UI macros (except as noted in Queries).

Each of these contexts will provide a slightly different set of expressions you can use. It is important to know the various contexts only so that you attune yourself to what to expect in each situation. For example, the FormatDateTime() function is not available in the Tables contexts but is available in all other contexts.

The best way to know what expressions are available in the context in which you are working is to use the Expression Builder or follow suggestions from IntelliSense. Although the designers catch many of the unsupported expressions in each context, they cannot catch every issue. Chances are that if you can’t create the expression using Expression Builder or IntelliSense, it’s not valid for that context.

TIP: If you find that the expression you want to use is not available in the context in which you’re working, try other contexts to see if you can incorporate your expression at a lower level. For example, the Hour() function is not available in the Forms context but it is available in the Queries context. In this case, you might create a query for your form that makes use of the Hour() function and then consume the result in your form.

Strict Type Coercion

One of the most difficult changes for traditional Access users to get used to is likely to be the addition of strict type coercion on the server. Access client will allow you to compare values stored in mismatching data types. For example, users can create a query that compares the value of a date/time column to the string “2009-10-02” and they will receive results from the query appropriate to the comparison. However, the same query will fail on the server because the user is attempting to compare a string and a date value. The only exception to strict type coercion is between dates and numbers, mainly because they are both stored internally as numeric values. For all other data types, implicit coercion is blocked on the server.

Because of this restriction, there are two common design considerations you should keep in mind when working with different data types.

When you work with Boolean values, always use the constants True and False instead of the numeric values 0, -1 or 1.
When you compare strings to numeric or date/time values use FormatNumber(), FormatPercent(), FormatCurrency() or FormatDateTime() functions to convert the field value to a string in order for the comparison to work on the server.

Query Optimization and Bound Fields

There are a few potential issues you need to watch for when creating expressions for web databases.

When you apply a filter or sort to a form or report by running a macro action such as OpenForm, OpenReport or SetFilter, any fields you use in the restriction must appear on the form/report in an expression or field that is bound to a property of the object or controls on the object. For example, if you call OpenForm and use the WHERE Condition

[MyField] LIKE “A*”

you must ensure that somewhere on your form you have bound [MyField] to a control or expression (it can be hidden if you like). For performance reasons, Access Services optimizes queries to exclude fields that are not bound to the page. Unbound fields are excluded from the final output query, regardless of whether or not they are included in the query designer.

Fully Qualified Control References

Another consideration to keep in mind is that you should fully qualify control references wherever IntelliSense suggests it, rather than using shortened references. This means that you may have to use the control reference

[Forms]![MyForm]![MyControl]

instead of the shorter reference

[MyControl]

This is especially true when referring to controls in subforms. Subform control references should be fully qualified as

[Forms]![MyForm]![MySubForm].[Form]![MyControl]

rather than a relative reference such as

[MySubForm].[Form]![MyControl]

As suggested earlier, you should make use of the Expression Builder and IntelliSense whenever you can to be sure that the expression notation you’re using is supported. Typing fully qualified references is much easier now with the changes to these features.

TempVars in Queries

When it comes to queries, Access Services does not allow you to refer to form controls or TempVars in stored queries. For example, the following query is supported in standard databases but not web databases because it contains a reference to a form control (highlighted).

In order to make this query web compatible, you could add a parameter to the query using the Parameters dialog (available from the Query Tools, Design ribbon bar) called “prmPartNumber”. The restriction in the above query could then be rewritten as below.

IntelliSense will support you here in that when you start typing the parameter name in the criteria, the parameter will show up as a member of the IntelliSense.

Optional Parameters

One final issue to watch for is that some functions that take optional parameters require you to fill in some or all of the optional parameters in order to publish your application to the web. A good example of this is Iif(). In client databases, you can use the Iif() function and leave out the optional, third argument, such as

=IIF([MyField]>5, “Large”)

In web databases you will get an error that the expression is not compatible with the web. You will need to provide the optional third argument in order to save the expression

=IIF([MyField]>5, “Large”, “Small”)

Similar issues can be seen with other functions that take optional parameters, so you should watch for this possibility when you run into problems.

Conclusion

There will be a learning curve for expert Access developers to adjust to the challenges of an application that can run in the browser on a hosted service. After a while, you will get the hang of the constraints around expressions but until then, IntelliSense should be your new best friend.

Power Tip: Making forms easier to use and maintain

cdowns — Mon, 25 Jan 2010 20:26:04 GMT

Reader Štefan Masič provides today's Power Tip.

In today’s post I would like to share with you some tips about form design that I’m using consistently in all applications I develop. Maybe you can get some benefit from my approach to form design.

As we all know, analysis and preparation of user needs are essential in building all elements of an application. This approach results in forms that are easy to use, are uniform throughout the whole application, and are easy to maintain.

Here are some design needs which must be satisfied on every Access form:

The name of a form must be easily visible.
The name of a form must be an expression of its functionality.
User must easily identify all mandatory (required) fields.
All mandatory fields should be visible on the first page of a form.
All fields with a default value, auto number functionality, or read only property should be designed with a different background color.

It is common to put the name of a form into the window’s title with the Forms!FormName.Caption property. I prefer to use the Form Header Section with the label called lblFormName. This label can be larger and is therefore much more visible.

Figure 1: Title of the presented form is larger and more visible than the window’s title.

In my applications all mandatory fields have bold labels with the additional foreground color, named mandatoryLabelColor. All mandatory fields are surrounded with the border color, called mandatoryBorderColor.

Picture 2: Mandatory fields are visible on the first view.

All mandatory fields are positioned on the first page. All other non-mandatory fields are positioned after first page break. With this design, the user can immediately determine which fields are required. All other fields are below them and on a second page, which is immediately visible with moving of the scrollbar. I prefer designing a form with page breaks and using the scrollbar for easy moving between pages. From my experience, this works better than a Tab control on forms with many fields.

All fields with default values, fields with the auto number functionality or read-only fields should have a different background color. For example: I use a yellow background color, called specialBackgroundColor. Additionally, all those fields have the AutoTab property set to No.

As mentioned above I use three colors, mandatoryLabelColor, mandatoryBorderColor, specialBackgroundColor. For all those colors I always use company colors or ask the customer to pick specific colors.

In my examples the following colors were used:

color of mandatory labels: Pantone 341 C (CMYK 100, 0, 70, 30 or RGB 0, 117, 84)
borders of mandatory fields: Pantone 166 C (CMYK 0, 60, 100, 0 or RGB 239, 124, 0)
background color of special fields: Pantone 109 C (CMYK 0, 10, 95, 0 or RGB 255, 222, 0)

If all the colors are determined during the analysis phase, and they’re not likely to change later, I always use a solution that does not require any programming. Here are Access numbers for all three colors, which I put into the appropriate properties of the labels and fields:

mandatoryLabelColor = LabelName.ForeColor = 5534976 (for Pantone 341 C)
mandatoryBorderColor = FieldName.BorderColor = 31983 (for Pantone 166 C)
specialBackgroundColor = FieldName.BackColor = 57087 (for Pantone 109 C)

Using global variables for more flexibility

If I think the customer might prefer different colors at a later date, I use variables instead of constants. This solution requires creation of a new module, with declarations of three public constants and three public variables. See the example modGlobalConstantsAndVariables below.

Public constants can be used when colors are defined in an early phase and are not likely to be changed. Public variables can be used when it’s possible that the colors might be changed in the future.

Module modGlobalConstantsAndVariables looks like:

'------------------------------------------------------------
' Element: Module, 2010
' Description: Definition of global constants and variables.
' - mandatoryLabeleColor
' - mandatoryBorderColor
' - specialBacgroundColor
'' Purpose : Global constants, global variables.
'' Author: Stefan Masic, january 2010
' Information: con = Constant; R=Red; G=Green; B=Blue
' See also: -
' Changes:
' (dd.mm.yyyyy, Author) Text
'------------------------------------------------------------
'--------------------------------------------------------------------

' Public constants.
Public Const conMandatoryLabelColor = 5334976 ' R=0 G=117 B=84
Public Const conMandatoryBorderColor = 31983 ' R=239 G=124 B=0
Public Const conSpecialBackgroundColor = 57087 ' R=255 G=222 B=0
'--------------------------------------------------------------------
'--------------------------------------------------------------------

' Public variables.
Public lngMandatoryLabelColor As Long
Public lngMandatoryBorderColor As Long
Public lngSpecialBacgroundColor As Long

'--------------------------------------------------------------------
' End of module
'--------------------------------------------------------------------

The simplest programming solution requires creation of a new OnOpen event on each form, with the following code for every mandatory field and every special field:

Private Sub Form_Open(Cancel As Integer)

On Error GoTo Err_Form_Open

Me.MandatoryLabelName.ForeColor = conMandatoryLabelColor
Me.MandatoryFieldName.BorderColor = conMandatoryBorderColor
Me.SpecialFiledName.BackColor = conSpecialBackgroundColor

Exit_ Form_Open

Exit Sub

Err_Form_Open

MsgBox Err.Description
Resume Exit_Form_Open

End Sub ‘ Form_Open

Storing color values in a table

When I’m creating a general purpose application where colors are likely to change, I use a special table, called tabDefaultApplicationValues. In its simplest definition, this table includes only one row and many fields. This table includes three fields MandatoryLabelColor, MandatoryBorderColor, and SpecialBackgroundColor. I also need function getDefaultApplicationValue(ValueName).

With this method, the simple procedure Form_OnOpen needs a little rearranging:

Me.MandatoryLabelName.ForeColor = lngMandatoryLabelColor
Me.MandatoryFieldName.BorderColor = lngMandatoryBorderColor
Me.SpecialFiledName.BackColor = lngSpecialBackgroundColor

Public variables can be filled during the loading process of Main form or Switchboard with the following code:

lngMandatoryLabelColor = getDefaultApplicationValue(“MandatoryLabelColor”)
lngMandatoryBorderColor = getDefaultApplicationValue(“MandatoryBorderColor”)
lngSpecialBackgroundColor= getDefaultApplicationValue(“SpecialBackgroundColor”)

Here is a simple function you can use to retrieve the color values from the table:

'------------------------------------------------------------
' Element: Function, 2010
' Purpose: Get value from table tabDefaultApplicatonValues.
'
' Input: Default value field name (String)
' Output: Value (String)
'
' See also: tabDefaultApplicationValues
' Avtor: Stefan Masic, january 2010
' Remark:
' Changes:
'------------------------------------------------------------

Public Function getDefaultApplicationValue(strDefaultValueName As String) As String

On Error GoTo Err_getDefaultApplicationValue

Dim dbs As DAO.Database
Dim rst As DAO.Recordset
Dim strDefaultValue As String
Dim strSqlStmt As String

' Check default value name.
If IsNull(strDefaultValueName) Then
  strDefaultValue = ""
Else
  ' Define current DB.
  Set dbs = DBEngine.Workspaces(0).Databases(0)
  strSqlStmt = "SELECT " & strDefaultValueName & " FROM tabDefaultApplicationValues"
  Set rst = dbs.OpenRecordset(strSqlStmt)
  ' Get value if record exists (rst.RecordCount>0).
  If rst.RecordCount > 0 Then
    ' Check NULL.
    If Not IsNull(rst.Fields(0).Value) Then
      strDefaultValue = rst.Fields(0).Value
    Else
      strDefaultValue = ""
    End If
  Else
    strDefaultValue = ""
  End If
  ' Free rst in dbs.
  rst.Close
  dbs.Close
End If ' IsNull

getDefaultApplicationValue = strDefaultValue

Exit_getDefaultApplicationValue:
Exit Function
Err_getDefaultApplicationValue:
MsgBox Err.Description & " (Error no.: " & Err.Number & ")"
Resume Exit_getDefaultApplicationValue

End Function ' getDefaultApplicationValue

If the solution requires personalization of default application values, or if the solution will be used by many companies, then this table will have two or more rows of default values for every configuration, and the function will have two parameters. Here are two examples:

getDefaultApplicationValue(UserId, ValueName).
getDefaultApplicationValue(CompanyId, ValueName).

The first described approach does not require any programming, and as such it is easier to manage the application over time and with new versions of Access. I recommend this approach.

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

Access 2010: Design more maintainable apps with calculated columns

Clint Covington — Sat, 23 Jan 2010 06:49:46 GMT

When I talk to developers about why they love Access, the most frequent response is always about fast they can build applications that track data. This saves time and money. Calculated columns are a new feature in Access 2010 that is designed to help end users and developers build applications faster, and are easier to maintain.

Let me start with a couple scenarios from the Access 2007 templates. In the Contacts database, there are two fairly complicated expressions that conditionally show either the name of the person or the company, depending on which is blank:

FileAs: IIf(IsNull([LastName]),IIf(IsNull([FirstName]),[Company],[FirstName]), IIf(IsNull([FirstName]),[LastName],[LastName] & ", " & [FirstName]))

ContactName: IIf(IsNull([LastName]),IIf(IsNull([FirstName]),[Company],[FirstName]), IIf(IsNull([FirstName]),[LastName],[FirstName] & " " & [LastName]))

The Sales Pipeline database has a similar scenario with a different expression that calculates the value of the potential opportunity:

ForecastValue: [EstRevenue]*[Probability]

In these two scenarios it is highly likely that if you are going to use data from either of the tables, you will also need the calculated fields.

In the templates, we created a base query that did a SELECT * and included the expression columns. Unfortunately, I see many poorly designed databases in which an expression is repeated throughout queries, forms and reports. When the expression requires modification, the database owner must look for the many places it may have been used so all the occurrences can be changed. With calculated fields, there is only one place to edit, so maintenance is faster and easier.

The main benefit of calculated columns is encapsulation, which leads to cleaner database design. It allows database developers to define the most common fields at the table level. This makes applications easier to maintain as inevitable bugs creep up in expressions (at least if you write expressions like I do :-) ). The developer can easily track the expression back to one place—the table.

Note: data macros are another example of a feature that allows developers to encapsulate logic in the table rather than behind form events.

Calculated columns are easy to create. Open the table in browse view. From the ribbon, select Table Tools | Fields | Add & Delete | More Fields | Calculated Field or choose the Calculated field type in table design view. Either way, the expression builder will help create the expression.

Another benefit calculated columns provide is consistency with SharePoint. Microsoft has made a big investment to make SharePoint a platform for collaboration and data applications. Calculated columns were introduced in SharePoint 2003 as a “calc and store” model, where values are only recalculated when dependencies change. This model is a performance optimization that makes it faster for the server to query against these values, especially when users sort and filter on the calculated field.

The calc and store model cannot be used for volatile expressions such as Date() and Now() because the stored result would only be accurate at the moment it is initially calculated. Functions that reference outside the row of the table, such as DSum, DCount and DLookup are also prohibited because it would be costly from a performance perspective to detect when dependencies have changed. These types of calculated fields are better left in base queries.

Calculated fields can save development time, reduce errors, and increase performance. This results in better-designed applications.

Enjoy!

March Madness schema

Clint Covington — Fri, 22 Jan 2010 17:32:22 GMT

Someone on the team wants to build a March Madness database. Anyone have a schema/database they wouldn’t mind sharing with the team? If we get something that works well—we might be able to share it with the community. Send us email if you have something and wouldn’t mind sharing it.

Thanks!

Use the IsClient() expression to conditionally run VBA from Web forms

Clint Covington — Mon, 18 Jan 2010 18:34:44 GMT

Today’s guest writer is Kerry Westphal the PM for the macro designer and browser logic.

Here is Kerry’s introduction on The Access Show on Channel 9:

We expect many advanced Access Services applications will have client and web objects—we call these hybrid applications. Hybrid applications are interesting because you can create client forms that leverage the full power of link tables, advanced queries, rich forms/reports, and VBA. See this previous post for more background on Web and client objects.

The IsClient() expression allows you to conditionally branch your logic depending on whether the form running inside Access or the browser. In this way you can have one button that runs a different macro based on the context it is called from. This allows you to take advantage of the full power of VBA and macros when the Web form is in the rich client while also using the same form to the browser. It makes application development much easier as you don’t have to create the same form twice (one for the Web and another for the client) to have different logic running based on the environment. I’m going to show three different examples how you can use this functionality in hybrid applications:

Open client verses server forms based on context.
Call a client macro from a button.
Call a VBA function from a button.

Open client/server form example

Using isClient(), you can open a different form based on whether the form is running in the client or browser. The design experience for Web objects and the compatibility checker allows you to open client and Web forms alike from your Web form. In the following example, you can drill through to a different contact detail form from the button of a contact ID depending on the environment. This is especially useful since the details form on the client takes advantage of functionalities that are unsupported on the Web details form.

Call client macro

The following example below is an example of extending the 2010 Contacts template to Save a Contact to Outlook using the IsClient() expression to run a client macro from a Web form.

The Save to Outlook button allows you to quickly save contacts to your Outlook address book from your Access database.

In the OnClick event for the Add Contact from Outlook button, check to see if the app is running in the Client and if so, then run the client macro AddFromOutlook that can run the client-only macro SaveToOutlook to open the dialog to save a new Outlook contact. Otherwise, when the button is clicked on the Web, throw a MessageBox saying that the functionality is unsupported.

Run VBA from a Web form

You can also run VBA from the Web form using the same syntax. The example below extends the Projects 2010 template and adds a task to Outlook every time a new task is added.

In the Save & Close button on the Task Details form, add logic to check if the form is running on the client. If so, then set up TempVars with the values from the form so it can be passed to the VBA function. We will call the VBA function from the onLoad event of a hidden form to get the VBA to add the task to Outlook to run. If the form is running on the Web, this code will not get called.

The onClick event on the Save & Close button opens a client form that triggers the RunCode call in the Onload event to run the AddOutlookTask code.

Hopefully, this post gives you some ideas about how you can combine Web objects with client objects and call VBA code from inside Web forms if the form is run in the Access client.

Enjoy!

Edited 1/19/2010 -- This expression is not available in beta 2. It will be available in RTM. Sorry for any confusion.

Access MVP recognition

Clint Covington — Fri, 15 Jan 2010 21:34:41 GMT

Today’s guest writer is Ric Lewis from the Access PM team.

Here at the beginning of the year we wanted to take the opportunity to highlight our MVPs. These are folks whose tireless efforts produce the vibrant Access community, which is a large part of what makes this such a great product. Many of them have answered thousands upon thousands of questions in newsgroups and on forums. Many of them have been involved in Access for more than 15 years. As a product team, we’re particularly grateful for their efforts, and we look forward to the chance to spend some time with them and recognize them at next month’s MVP Summit.

Walter Niesz (Website) Author of multiple How To and FAQ on Utter Access. Walter is the unquestioned master of the pictorial tutorial.

Scott McDaniel (WebSite) Genius three times over on Experts Exchange, making him not only one of the top Access Experts, but a perennial top 25 across the entire site.

Oli S (Website) A ribbon master and all around Access Freak, with over 30,000 answered questions to his credit on UtterAccess and other fourms.

Larry Linson (Website) (N. Texas Access SIG) Enjoying 16 years as leader of the Access SIG in North Texas, Larry is a prolific contributor to Access newsgroups, contributing an article each month to the North Texas PC News. He’s currently collaborating on a book with other Access MVPs.

George Hepworth (Website) "Grover Park George" is an Admin at Utter Access, as well as an author and blogger. He is known for focusing on newer users, helping to make sure their first experience in Access is a good one.

Bob Larson (Website) You can't throw a rock without hitting some Access Forum where Bob is posting. He's established a strong presence on nearly a dozen different Access forums, most recently on Microsoft Answers.

Gord Hubbell (Website) Gord is webmaster of what is arguably the heart of the Access community, UtterAccess.com. Gord's passion and commitment to developing the Access community have borne fruits to everyone from first-timers to those of us who develop the product.

Emilio Sancha (Website) (Spanish Forums) Emilio had already been playing with Access for nine years when he discovered the existence of the Microsoft Newsgroups and was opened up to a new world of social Access. He is a regular contributor the forums and newsgroups.

Roger Carlson (Website) Owner of two major repositories of Access wisdom, Roger has been contributing on Access-L, UtterAccess and MS Access newsgroups for years.

John Viescas (Website) John is a prolific writer, authoring five Access books, and co-authoring another. He has been an Access MVP for 16 years and running.

Andrew Couch (Upsizing site) (AUG Community) Andrew is director of the UK Access User Group (www.ukaugcommunity.co.uk) and a regular speaker at UK Community Events. He specializes in migrating Access applications to SQL Server and .net. He is also the technical developer behind the popular migration toolset MUST.

Leo (theDBGuy) An UtterAccess.com VIP who has been giving sage advice to Access users all over the world with their database questions.

John Mishefske (Website) John Mishefske provides samples that can be downloaded from his Tigeronomy Software site that contain full source code as well as code and Jet SQL examples for common problems faced by Access and VBA programmers.

Garry Robinson (Website) (Smart Access) Garry earned his Access MVP stripes writing for the very popular Smart Access magazine from 1998-2006 and when that closed down he moved on to Database Journal. He has since bought the rights to the Smart Access archives and published their content online.

Thomas Möller (Website) (German SIG) Thomas is a jack-of-all-trades, posting in forums, running the oldest German Access SIG, authoring for Access im Unternehmen and lecturing at the German Access developers conference AEK.

Glenn Lloyd (Website) Glenn Lloyd is an independent Access Developer, Office Applications trainer, and Forums Administrator at UtterAccess.com. He publishes a blog for Office application fans and users at www.officetipsandmethods.com.

Tom van Stiphout (Contact) Active in public newsgroups as well as on his Access security blog. Tom recently contributed to an Access book in response to a challenge from Steve Ballmer in last year's conference.

Graham Seach (Contact) Co-author of the canonical Access 2003 VBA Programmer's Reference. Graham is active in newsgroups and as a speaker. He is currently working with an Australian university on various ways to include Access in the curriculum, including developing a BS degree program in Workgroup Systems (essentially a degree in Access development).

Cinzia Pagani (Website) (Twitter) Cinzia is active in the Italian Access NG and Social Forum. He also serves as one of the webmasters of RIO, an Italian language site for FAQs and article on Office development.

Miriam Bizup Miriam is a Zone Advisor for Access topic areas on Experts-Exchange. She also contributes to articles as a Page Editor for the database and programming areas, acting as a moderator for site-wide support issues.

Gina Whipp (Website) The largest thread on the MVP forums in the last month has been the thread welcoming Gina to the MVP group. We're glad to finally have her insight and efforts recognized in this setting.

Crystal Long (Website) Crystal has produced numerous Access learning materials, from her free “Access Basics” book, to her video tutorials on her own YouTube channel (http://www.youtube.com/user/LearnAccessByCrystal). She is also a frequent contributor on multiple Access and Excel forums.

Alex Dybenko Active in MS Access newsgroups for years and on his Access blog (http://AccessBlog.net).

Joe Anderson (Website) He has been working with Access since 1.0. He’s in the Microsoft Access Hall of Fame on Experts-Exchange.com, as well as owner and CEO of All Data Corp.

Power Tip Link: Delete records by using a delete query

cdowns — Thu, 14 Jan 2010 07:58:00 GMT

Today's guest author is Luke Chung, President and Founder of FMS, Inc.

DELETE queries are a fundamental part of relational databases since you can remove multiple records at one time, and can specify which records to delete by linking to data in another table.

Delete query option in query Design View

Delete queries let you:

Empty a table (delete all its records)
Delete all records with a particular value in a field
Delete all records with a range of values in a field
Delete records based on criteria in multiple fields
Delete records with matching values field(s) in a joined table

Read the article on Luke’s site to learn more about DELETE query SQL syntax, how to avoid deleting historic data, and get examples and troubleshooting tips.

Luke has written and presented a wide range of topics related to Access over the years. In addition to their many Access related products, FMS offers a wealth of great Access papers, tips, and video on their site.

Get your favorite Power Tip on the Access Team Blog! Send it to Mike & Chris at accpower@microsoft.com.

Ping Access 2010 book authors

Clint Covington — Thu, 14 Jan 2010 04:36:00 GMT

Are you writing a book about Microsoft Access 2010? If so—we would like to help you write a great, accurate book. Please email us your contact information and a bit about your project so that we can follow up.

Cross version compatibility between Access 2010 and Access 2007

Clint Covington — Wed, 13 Jan 2010 17:00:00 GMT

Today’s guest writer is Lois Wang—PM for reports and version-to-version compatibility.

I saw a question on the Access TechNet Forum the other day that I’d like to share with the community:

“I can't open accdb files in Access 2007 after they've been opened in 2010.”

Access 2010 brings you many new features (Data Macros, Calculated Columns, etc.) that Access 2007 does not understand. If Access 2007 goes ahead and open a Database created/modified in 2010, it will ignore these new features and might even cause data loss or corrupt business logic. For example, a data macro validation rule that is forced in 2010 but ignored in 2007, this can cause data inconsistency. To prevent that from happening, we implemented the feature to block certain databases to open in Access 2007 after it's modified in 2010, or open it as read-only in 2007.

Access 2007 cannot open a database built or modified in Access 2010 if it uses:

new sort orders,
Access 2010 new encryption, or
your application has been published to SharePoint.

For other new features as Data Macros, Calculated Columns, Navigation controls, Web browser controls, and new layout for forms/reports, we did the work to allow the Access application that contains these features to open up in Access 2007 SP2, but objects containing these features are read-only. However, the application does not open in Access 2007 SP1, so please make sure you get SP2 for Access 2007.

What if the people you want to share your application with only has Access 2007? There is a way to “down-grade” your 2010 application to 2007. In short, delete the new features in your application and import all objects into a new Access 2010 blank application. This will create a new app that can work in Access 2007.

The article on http://msdn.microsoft.com/en-us/office/cc907897.aspx has more details.

Access in Washington, DC

BenHodes — Tue, 12 Jan 2010 20:45:00 GMT

This Thursday, January 14th I will have the distinct pleasure of speaking to the Washington DC SharePoint User Group. I’ll be giving a talk on Access 2010, Access Services, and our much improved database manageability story.

I currently have some time free from 10am to 4pm on Friday, January 15th, and I’m actively looking for someone in the greater DC area who would like to talk about their experiences with Access. I’d be excited to visit you at your place of work, whether you work alone, in a company of 100,000 people or in any situation in between.

So if you’re in the DC area and are interested in some face time with the product team, I’d love to meet you. I probably only have time to meet with one or possibly two people face to face, but if we can’t visit you in person, we’d be happy to set up a phone call or a Live Meeting after we get back.

If you'd be interested, please send me an E-mail (BenHodes@microsoft.com), and I’ll get in touch!