The Issues Tracking Application in Detail

Published 09 February 06 10:21 AM

The Issues tracking application is a great example of the set of tracking apps mentioned last time.  It is quite simple - only 2 primary tables (for Issues and Contacts), a few forms, and several reports.  One of the goals for the tracking apps was to make them super simple to customize, so the Issues application has no code (other than macros), few queries, simple schemas, and so on.  It is fully functional as it stands, but we expect end users to be successful adding new fields or tweaking the forms & reports.  I'll discuss how users will customize the application in the next post.  The schemas for the issues and contacts tables are shared with SharePoint, so if the application is upsized to SharePoint, you'll get the benefit of the server recognizing those lists and providing richer browser UI for them. 

Getting Started

Users will start with the tracking apps from the Getting Started screen.  After they select which app they'd like to use, they get a choice on the right side to give it a name and choose whether they'd like to start with the application on a SharePoint server.  If they choose to start locally, they can always move to SharePoint later.

Issues List

Once the user creates an Issues tracking application, she is taken to the default form, the "Issues List" and she's ready to go.  The issues list is a new Access 12 "split form", with the top part used for navigation buttons and the bottom datasheet used for data entry. 

(Click image to enlarge)

Access 12 has a new property that allows you to make the background of buttons transparent, so you can easily create the rich look above by simply putting an image behind the buttons and then making them transparent.  Each of the buttons on the form fires an Access macro, which is embedded in the button and comes with it, for example, on copy / paste operations.  So if the user wants to create a new form that has a link to the New Issue form, she can simply copy the button and it will continue to work from the new form without modification. 

Drill Through to Contacts

One of the key challenges of data applications has always been helping users maintain referential integrity.  Access has always supported RI, but it has always taken VBA code for Access developers to take users from a data selection control in one form to the detailed form they need to fill out first.  Access 12 makes this possible through macros, and can take the user to the right UI to enter the data.  In the example below, the user has typed a name in the "Assigned to" edit that isn't in the Contacts table.  Access offers to take her to the right table, and pre-populates 'Last Name" with the text typed on the Issues form.

 After the user clicks Yes, she is taken to the Contact Details form, where she can enter the rest of the data for "Rucker".

(Click image to enlarge)

In addition, there's a Contacts List form for quicker entry of contacts, much like the Issues List form.  Navigation between them is through the buttons on the right side of the header of the two forms.

(Click image to enlarge)

Live Reports

Access 12's reports are now live when viewed on in the application, allowing the user to select and copy data, and to drill through the report to more detailed data.  In the Issues tracking application, most of the reports drill back to the underlying detailed forms for Issues or Contacts. 

(Click image to enlarge)

 

When the user clicks on one of the hyperlinks in the title column, she'll be taken to the Issue Details form for the appropriate issue.

 

Next Time

Next, we'll take a look at what the user will have to do to customize the Issues tracking application.  This will show some more of the details on how the application was built and show off more of our authoring tools.

by Erik Rucker
Filed under: , ,

Comments

# AL said on February 9, 2006 2:15 PM:
Looks nice so far!  I especially like the interactive reports.  Do they print as they appar on screen, after the user has played with them?  Or do they print in the form they were designed?

Is it possible to create a vertical split (e.g. explorer style) in the form, with record navigation (Record list) on the left or right of the data entry area?
# Erik Rucker said on February 9, 2006 7:24 PM:
Thanks!  The reports print largely as they appear on screen, but the hyperlinked column will print just as text so its easier to read.  If you modify the columns and so on, you're really changing the report, so they print with your changes.

There's no easy way to build an explorer-like UI in the report, but you could build a form like that.  Still not super easy, but could be done.  
# DmitryKo said on February 9, 2006 9:20 PM:
I don't think I understood the logic behind SharePoint-enabled scenario. Is there just an Aceess 12 file put to a web page so the user can download it over HTTP? OK he then opens it  and makes some changes - what happens to the version stored in the SharePoint then, and what if multiple users have opened the same file? Or the file is actually opened roght from Web location as if it were on a local/network disk, and all the changes are commited to SharePoint in realtime by HHTP? Or it's a web-based form/report that is connected to the Access 12 running  in the background on the SharePoint service? Please excuse my ingorance, I have absolutely no background in SharePoint...
# AL said on February 9, 2006 10:12 PM:
How many simultaneous Access users could SharePoint support?  Can I fill combo boxes quickly with SharePoint lists?  Can this SP solution scale to hundreds of concurrent users????  Could you give us some idea of how Access talks to the SharePoint server: SOAP Web Services, ADO, ...
Is the SharePoint solution suitable for a large Enterprise application? Is SQL Server/ADP or SharePoint better for the back end on a system with many users?  Can you give us an idea how client and data security is managed for a SharePoint solution?
# Alan Cossey said on February 10, 2006 11:31 AM:
One of the pictures does not appear because its source is set to file:///C:/Documents%20and%20Settings/erikr/My%20Documents/Public/Access12/Blog%20Entries/IssuesListThumb.JPG
# Stevbe said on February 10, 2006 12:30 PM:
Could you please post a / some screenshots of the entire Access window so we can see how the forms look and what their relationship is to the *ribbon* is?
# Erik Rucker said on February 10, 2006 12:46 PM:
Sorry about the busted image, got that fixed.

Here are some answers about the SharePoint work with more to come in future posts (there's a lot there).  What happens when you move a Access database to SharePoint is the data gets moved to WSS lists, and the .accdb gets moved to the server as well.  When someone opens the database they get the front-end sent over the wire, pointed at the backend data.  This works great with multiple users, since the data is shared.  If a user wants to change the front-end, she can use SharePoint's "check-out" feature to get a write-lock on it, make changes, and save back to the server.  Now when the next user opens the app, he'll get the new updated database.  There's not a lot of content there yet, but it would be worth looking at http://blogs.msdn.com/pjhough for more on SharePoint.

Access with SharePoint can handle a lot of concurrent users - breadth scale works great and hundereds of users should be no problem.  Table size is harder for SharePoint and tables with more than 10's of thousands of records may be slow.  For those databases and for Enterprise applications, SQL Server is better for a backend.  SharePoint works better for broad, flexible, and collaborative solutuions.  SQL Server works better for deep, large volume, and highly managed applicatons.  Access works great building UI for either.  

SharePoint has fairly fine-grained security, and allows per-user security, groups, and so on.  I'm not sure I can accurately represent all the details there, but they'll be coming from the SharePoint folks soon.
# Abigail said on February 10, 2006 1:20 PM:
AL,
It is possible to make something *like* explorer-style forms. The new Split Form option is available as one of the default styles for Form View (along with Single, Continuous, Datasheet, etc.). You can choose to have the datasheet on the top, bottom, left or right. So you could conceivably have the datasheet on the left, hiding all but the one or two columns that make navigation easy, and have the detail form on the right. You could make the datasheet on the left read-only, which would prevent accidental edits, but clicking on any record in the left-side datasheet would bring it up on the (editable) form on the right. Not perfect, but relatively simple.
# AL said on February 11, 2006 8:13 PM:
Abigail,

Regarding: "Not perfect, but relatively simple. "

I don't know- that sounds pretty perfect to me!  That's exactly what I've been coding by hand - a great time waster.  An automatic treeview would be nice, but that's a luxury for now.  I suppose one can also do a subdatasheet, if necessary.

BTW, are you part of the Access team, or just happen to have an early beta?

AL
# Abigail said on February 13, 2006 12:51 PM:
AL,

I'm an Access Dev, and my features (enabling some design capabilities with live data) overlap with split forms.
# A discussion of what's new in Access 12 said on February 13, 2006 2:15 PM:
Last time, we looked at the Issues tracking application that will ship with Access 12 and provide a simple...
# Rich Bulan said on May 23, 2006 4:36 PM:
Access 12 seems to have some nice improvements. Have there been any enhancements made to the SQL View? One of the features that I miss in Paradox was the clean SQL that it produced, and the color coded text (syntax highlighting) as well. Even the ability to increase the font would be much appreciated.
# gay rape said on June 2, 2006 6:59 PM:
We are wellocme to it's configuration.
New Comments to this post are disabled
Page view tracker