Analysis of Stadium as a model driven development tool - Part 1

What is model driven development (MDD)?

In model driven development, a software application is described using models. These models are specified at a higher abstraction level than conventional programming languages. These models are then transformed into a working application by generating code from the model or interpreting the model. In other words, instead of using code to develop applications, users start with a model and the model is transformed into code using a tool.

The idea that models should drive software development is more than 20 years old.  In some cases the tools were only able to generate code templates and the rest of the code had to be written in a conventional way. A common factor in all these approaches is that the proper use of models raises the abstraction level and one can cope with complex systems with less effort.  This can be compared to the evolution of programming languages from assembler to modern high-level programming languages such as C# and Java.

There are some key functionality areas when assessing MDD tools.  It can be divided into modeling support and development support. This blog post will cover modeling support for Stadium. Development support will covered in another blog post.

Modeling support

Abstraction'The ability to enable work on the correct abstraction level for the given task'

The aim of this abstraction is to increase productivity. However abstraction comes with a downside, designers can't change every minute detail they want. If this kind of functionality is needed, we might as well go back to programming. So yes, it comes with rigidity.

In Stadium, designing of pages and configuring of actions are done via models.  These are at a higher level of abstraction i.e. users do not have to worry about javascript, mechanisms used to connect with database, the mechanics involved in executing a query.  These concepts are hidden away from the designer of the application. This is something you will greatly appreciate if you know how many lines of code these abstractions map to.

Stadium however does not abstract sql queries. Stadium designers need to be experts at writing sql queries .

Understandability'The ability of the models to be understood by stakeholders'

From a designer perspective, the model for designing pages is very simple and easy to understand with some introduction. However if the models are seen as a mechanism for communication between designers and business stakeholders, Stadium falls short. Stadium's designer does not have a WYSIWYG forms model and thus cannot be used for communication purposes e.g. grid control is displayed as a single control in the  forms designer, its columns cannot be seen. It can only be seen when the sap file is uploaded on the website.

The model used for calling actions is very simple. However in the case of some actions e.g. decisions, the display can get quite complex and it would be ideal if there was some mechanism to 'package' actions  and drill down only if necessary. This will improve the understandability. 

 It is also worth noting that the notations used for the models are custom notations and do not follow any industry conventions.

Executability'The ability to work incrementally to examine system properties by experimentation.'

The models can be executed fairly easily in Stadium. Designers only have to save the models, upload and view it.  Designers can work iteratively and see changes taking effect. However it is a bit cumbersome as there is no one click and deploy mechanism. Users have to continuously switch between the designer and web application to see changes. There is scope for improvement in this arena.

Model transformation and refinementA transformation is basically the process of extracting the model information and using this information to create a new artifact, for example a unit of code in a language like Java or HTML.  A tool with refinement support allows the designer to define custom refinement rules/model transformations.

In Stadium3, there is no way to define or change how the models are interpreted,  or to define custom transformations.  Stadium provides fixed models  to build web applications. This does keep Stadium very simple.

Stadium designer does not currently have enough support for ensuring correctness of the models. Designers have to upload the applications to check for errors.

Stadium3 Release : 3.2.1952.4311

Build 3.2.1952.4311 is available for download. It includes:

New Features

• New search feature in designer - Designers can now search for pages, controls, connections etc
• New ChildGridIterator action for iterating child grid rows
• Filter fields - Default values can be obtained from database
• New system variable for logged in user name
• DataGrid Image column can now get image url from database

Bug fixes

• Panels with fixed height now display scrollbars
• Maintenance message will be displayed to users when refreshing an application
• Security is applied when navigating to pages directly
• Fix for messagebox not responding to Enter
• Link control on master page now works

Looking forward to feedback on the new features.

Note:

• This will be the final release for this year
• This is also the final release on Framework 3.5

What next:

• Upgrading to Framework 4.0
• Making some small changes to make Stadium look better, like Johan said 'putting some lipstick on'......

On a personal note, I have really enjoyed the interactions with all the stakeholders of Stadium, especially this year.  I have learned a lot from you, thank you!

Stadium usage statistics

We have performed an analysis on all the Stadium applications that are currently running at our clients.  The aim of this excercise is really about learning and gaining knowledge about how Stadium is used.  It will also be used in future when identifying opportunities and developing enhancements.

Top 10 applications (based on page count)
Name	Pages
LinxBusinessBanking	1102
Bulk Deregistration	321
MultiManager	150
LeadProcessing	106
MonthlyMultiManager	106
BlueHawk	99
StandardBankDataDictionary	98
DailyMultiManager	91
Nimitz	89
OMIA_3_staticdata	89

Least Used Controls
Name	Instances
Guage	0
CheckBoxList	1
RadioButtonList	1
RSSFeedViewer	1
TreeView	1
ReportListViewer	2
ReportViewer	11
URLViewer	14
RDLViewer	15
Chart	20
TextBox	27

Least Used Actions
Name	Instances
CallAssemblyMethod	0
CallWebService	0
ExportToExcel	1
CheckBoxListIterator	2
SaveControlValues	14

Adding Filters can be Easy (and when incremental design could result inbewilderment)

Just about every Stadium page contains a filter and a datagrid. This is why we thought it would be a good idea to spend some time thinking about how we could make it easier to set these up. Adding a filter to a datagrid can be a lot easier.

We realised that we were forcing our users to do a lot of tedious filter configuration that could be done for them most of the time. Making changes to Stadium Designer is a time-consuming exercise, but if we can save time for our users by making it quick and easy to create and maintain pages that contain the good ol’ filter-and-datagrid combination, our time would have been well spent.

Let’s take a step back and think about this. Imagine that you need a page that displays employee information. You would like to be able to see: names, surnames, some form of ID number, birth dates, phone numbers, addresses and a couple of other applicable bits of information. You want a datagrid that looks something like this:

Employee Datagrid

You also know that you want to be able to filter by ID, name and surname. To do this, you should be able to tell Stadium four things:

1. I want a filter, and I want to filter by
2. ID number,
3. Name and
4. Surname.

Stadium should be able to do the rest.

We discussed a couple of ways that we can allow our users to do this. We agreed on one and I went and put together a quick paper prototype.

The idea is this: once I have a datagrid, I should be able to add a new filter to my grid (by either right-clicking on the datagrid or selecting a “New Filter” option on the existing datagrid “Filter” property) and then be allowed to choose which columns I want to filter by. In other words, the steps would be:

STEP 1: Configure a datagrid.

Datagrid configured

STEP 2: Select “New Filter” from a Filter property dropdown or from a contextual menu on the grid.

Contextual menu or New Filter... option in dropdown

STEP 3: Check which columns you want to filter by.

Select columns from a checkboxlist

STEP 4: Hit Save, and there you have your filter.

Filter and datagrid

The filter is configured for you, with some important assumptions made. If you aren’t happy with our assumptions, you are allowed to edit the filter by opening the filter’s Field Editor.

The assumptions that we can make, should we go this route, are:

1. Datagrid column headers and filter field labels are always the same. E.g. if my datagrid has a column with header “EmployeeID” and I specify it as a column I want to filter by, the filter field created for me will be named and labelled “EmployeeID”. If I edit the column’s header later on, the filter field will be updated:

   

   Synchronisation of field labels and headers

2. The order in which datagrid headers and filter fields appear, match. E.g. if my datagrid has three columns, headered “EmployeeID”, “FirstName”, “LastName” and “Birthdate” and I specify that I want to filter by employee ID and date of birth, the filter fields will be ordered with “EmployeeID” first and “Birthdate” last. If I edit the order of my columns later on, the filter field order will be updated.


3. Filter fields are defaulted to type “TextBoxField”, except if the data comes in Date format, which case we assume that the filter field is of type “DateField”. We will not attempt to figure out when a field is or should be of type “DropDownField”.


4. If a filter is dragged right above a datagrid in Stadium Designer, the filter is associated with that datagrid by default and we make it easy to add that grid’s columns as filter fields.

In addition:

      5. If a column of a datagrid is deleted and it was included as a filter field, the filter field is deleted.

      6. If a column of a datagrid is hidden and it was included as a filter field, the filter field is hidden.

      7. It is still possible for a filter to act on multiple datagrids, but this becomes the “difficult-but-possible” route, because we can safely say that this is an edge case.

We hoped that we would be able to break the feature up into two main parts. During the first iteration, we would only implement the “quick” filter creation route, where a new filter is added by right-clicking on the datagrid or selecting New Filter… from the datagrid Filter property. During the second iteration, we could start making changes to the current Filter Field Editor to allow our users to add and remove filter fields from there:

A new filter Field Editor

Usability Testing – Round One

We tested the first part of our idea by making a paper prototype and putting it in front of five of our designers. We quickly ran up against a serious discoverability problem. Our designers have learned to follow a particular procedure when creating filter-and-grid pages: drag a filter onto the page, drag a datagrid onto the page, configure datagrid columns, configure filter fields, reselect the datagrid and then map filter fields to datagrid columns.

This meant that not one of our designers discovered that they could add a filter from their datagrid. Our first round of testing revealed two more important things. The first was this: our designers think of the filter control as an addition to a datagrid, rather than a self-sufficient entity. Two testers wondered out loud why a filter was a separate control at all. (The reason that a filter must be a separate control in Stadium is because, in rare cases, users want to filter two datagrids using the same filter). The second thing we learned from our tests was this: implementing the first part of the design only, without altering the current filter Field Editor, would probably cause a great deal of confusion. If designers didn’t know about the new feature, they could happily follow the current method and configure filter fields that are entirely independent of their datagrid. Once they then reselect the datagrid and start mapping fields, they would be presented with the option to select which datagrid columns they want to filter, which would make all their hard work configuring filter fields superfluous.

Usability Testing – Round Two

We changed our prototype to include the changes to the Field Editor. This time, the designers followed their usual procedure, but when they got to the point where they had to configure the filter fields, they were presented with the option to simply select the columns that they wanted to filter:

New filter Field Editor - nothing checked

When a column header is checked, it becomes selected and the filter field can be edited as usual, with the only differences being that:

• Field Type (whether the filter field is a DateField, TextBoxField or DropDownField) becomes a property of a filter field that can be changed at any time.
• Field Label is displayed as a non-editable property (determined by the datagrid column header).
• Datafield is displayed as a non-editable filter field property.

New filter Field Editor - Cycle Date checked

We have concluded that this feature is the kind of feature that should rather be implemented as a whole, or not at all. Interestingly, an incremental improvement is likely to cause quite a lot of bewilderment.

Upgrade to Framework 4.0

Stadium is currently running on .NET Framework 3.5. We will be upgrading to Framework 4.0 soon.  Some further information regarding this:

• Why the upgrade?
  .Net Framework 4.0 has a lot of new features and improvements which we will be able to use to improve Stadium. All new framework features are documented at:
  http://msdn.microsoft.com/en-us/library/dd409230(VS.100).aspx


• Will existing Stadium applications require any changes to work on the new version of the framework?
  Stadium application files i.e. sap files will require no changes. It will work as is on the new version of the framework.


• What are the system requirements for Framework 4.0?System requirements, download and instructions can be found at:
  http://www.microsoft.com/download/en/details.aspx?id=17718

Any other questions?

Feature peek - Test query

As a designer of Stadium,  it would be great if SQL queries used for controls e.g. SelectQuery of DataGrid could be tested within the designer environment so that he/she can be sure that the query is correct and also displays the expected data.  We are introducing the 'Test query' feature in the designer for this purpose.  This will also speed up implementation time as designers are currently using database tools or uploading the sap file and viewing it on Stadium's website to confirm query is correct, this additional step won't be necessary.

A test section will be added to current 'Command Editor' dialog. It will have two tabs: Test Inputs, Test Results as indicated in below screenshot.

  

The 'Test Inputs' tab will be pre-populated with parameters as and when parameters are added, see below wireframe.

User can specify test values in and click on 'Test' button. Results of query will be displayed in 'Test Results' tab as shown below:

Please note these wireframes are rough and gives a an idea of current thoughts and may change when implemented. Thanks to Carien for designing and wireframing the screens for us.

Feedback and comments will be much appreciated.

Stadium3 Release : 3.2.1917.4213

Build 3.2.1917.4213 is available for download. It includes:

• Fix for dependant dropdown values not remembered when 'SaveFilterStateOnApplyButtonClick' property is set to True
• Fix for RefreshParameters button not working on command editor for Text property of label
• Fix for RDLViewer control not working with date parameters
• Fix for issue when RefreshControls action was used to set Panel to visible
• Fix for index out of bounds array when expanding childgrid
• Panel - Fix for issue with wrapping of text when it is collapsed
• User will now be locked out after three failed log in attempts
• Applications displayed in 'Select an application' list can now be ordered
• All folders are now collapsed by default in designer
• Folders can be moved in designer
• RefreshControls action now includes treeview control
• Designers can now find all occurrences of user controls, connections, custom settings, validations, access rights, pages, access rights, master pages in designer
• Filter - 'Include' checkboxes cell is checked automatically when user types in filter value
• Filter - TextBox fields now have 'Like' as default condition in designer
• TreeView - Node has new ColourField property
• TreeView - New path control property
• New ExportToExcel action
• DataGrid - New sql query source for link column
• ChildGrid - New LeftMargin property
• Creating a new application in designer creates a new page and master page automatically
• Finally it is now possible to refresh an application via Admin->Manage Applications page,  designers don't have to upload the changed sap files.

Note: It is likely after you upgrade and open the designer, the various panels: Application explorer, user controls, events are located at incorrect positions. The StadiumDesigner.Docking.config file contains the panel location settings for each user. This file will have to be deleted for the panels to be reset to original locations.

This config file can be found in the user's roaming application data folder for Stadium. This is typically located in the following directory:

Windows 7 & Windows Vista:
C:\Users\<UserName>\AppData\Roaming\Twenty57\Stadium

Windows XP:
C:\Documents and Settings\<UserName>\Application Data\Twenty57\Stadium

Enabling server side paging on grids

With the release of version 3.2.1882.4128 of Stadium3, we have server side paging in Stadium3. It took lots of hard work to implement this and I am hoping it will be widely adopted by Stadium designers when designing data intensive applications.

What is server side paging?When displaying data for a grid, Stadium will fetch all the data from the database server and load a specific number of records depending on the value of 'pagesize' property of the grid.

Assume that a grid has 10,000 records and the page size for grid is 50. When the user clicks on Page 2, the application will fetch all the 10,000 records from the database server and then load records 51 to 100 to the grid control on the web page. This means that  we are fetching a lot of records which we really do not use. By fetching only the records that we need (in the above example, records 51 from 100) from the database server, we can gain better performance at the database server level as well as at the application level. This concept is called server side paging.

How do I enable server side paging?

Special Tags in query

There are some special tags that need be part of the SelectQuery of the grid:

• {%PagingDefaultSortColumn%}
• {%PagingStartIndex%}
• {%PagingEndIndex%}
• {%FilterSearchCondition%}

{%PagingDefaultSortColumn%} - This tag indicates which column to sort on

{%PagingStartIndex%} - This tag indicates the starting record number

{%PagingEndIndex%} - This tag indicates the ending record number

{%FilterSearchCondition%} - This tag indicates where the filter criteria will be placed.  If there is no filter it is simply replaced with '1 = 1'.

Stadium will replace these tags whenever the query is executed. These tags serve as placeholders so Stadium knows where to replace appropriate values.

New DatabasePagingDefaultSortColumn property

This is a new property on the grid.  It indicates the default sort column on the grid when it is initially displayed. This field is required for server side paging.

Query structure

The query has to be written in a specific manner,  so yes, you have to sweat it out! My simple query to return all employees changed from:

'Select * from employees'

to

'WITH EmployeeRows AS (   SELECT ROW_NUMBER() OVER (ORDER BY {%PagingDefaultSortColumn%}) AS EmployeeRowNumber, *   from       ( select e.employeeid, t.territoryid, e.firstname  FROM Employees e   left join EmployeeTerritories t ON e.employeeid = t.employeeid) AllData  where {%filtersearchcondition%} )

SELECT (SELECT Count(*) FROM EmployeeRows) AS StadiumRowCount, EmployeeID, TerritoryID, FirstName FROM EmployeeRows WHERE EmployeeRowNumber BETWEEN {%PagingStartIndex%} AND {%PagingEndIndex%} '

Stadium designers are SQL experts, so this should be easy.

Note:

• The query itself may not execute faster on database server. In some cases it maybe slower than before as sql server is doing more work now.  Speed of query execution will depend on the query and data.
• Performance and memory usage will be better on the web server as there is less data,  so if you are getting out of memory errors,  server side paging should be used.
• Less data will be transmitted over the network.
• Does not work with stored procedures.

Changing the colour of visited links on grid

With release 3.2.1882.4128 of Stadium,  there is a new property 'ApplyVisitedLinkColour' on link column of datagrid control. The default value of this property is False. Set it to 'True' if you want the link to change colour once the link has been visited by user.

Please note below:

• If this value is set to True, DataKey property on DataGrid must also be set, this is so that each row can be uniquely identified.
• DataKey property should be the name of column, typically an ID column
• It only changes the link colour while user remains on the same page.  If user navigates away from the page and returns to the same page,  colour of link will revert to original colour.

When should I change the colour of a visited link?

http://bit.ly/o8Ioaa

Depending on the scenario, Stadium designers will have to judiciously use this property.

Stadium3 Release : 3.2.1882.4128

Build 3.2.1882.4128 is available for download on Storytracker. It includes:

• DataGrid has now server side paging option
• GridIterator action now allows actions to be performed for all rows in a grid, not just the rows on active page of grid. Use this with caution, if there is lots of rows in grid, it will slow down and have an immediate effect on performance.
• DetailsView - Formatting of data is possible with new FormatConditions property
• RefreshControls action now includes DetailsView control
• Tab order on detailsview, datainput and filter controls  is retained after changing values in dropdowns
• ApplyVisitedLinkColour property on link column can be used to change colour of already viewed links
• TreeView has new Expanded property to indicate if a node should be expanded by default or not
• The text and value of selected node on treeview can be used in actions
• SetControlProperties action can now be used to display or hide a panel
• Fix for error that occurred when opening a file in a child grid

Please take note:

• All sap files will have to be first loaded in designer to upgrade to latest format

Thanks for all the feedback, please keep them coming.

How to remember page of grid

Consider the following scenario:

• User views a grid on a page as displayed on Screen1
• Notice the active page on the grid is page '2'
• User then clicks on 'Edit' link on any row of grid
• User navigates to another screen Screen2
• User then clicks on Cancel button on this screen to return to page with grid i.e. Screen1
• Ideally when user returns to this screen, page '2' should still be the active page.

This was not possible but is now possible with the latest version. It can be configured as follows:

• DataGrid control has a new 'CurrentPage' property, see Screen3
• The default value of CurrentPage property is 1 i.e. first page
• This property can be configured to the value of a page parameter
• If the value of page parameter is empty, grid will default to the first page
• When navigating from Screen1 to Screen2, pass the  current page of grid as a page parameter to Screen2
• This can be done by making use of new 'CurrentPage' control property of DataGrid, see Screen4
• When navigating back  from Screen2 to Screen1, pass the page parameter value back, see Screen5
• The 'CurrentPage' property of grid should be configured to be this page parameter

This is a really nice feature and will no doubt please our precious users and improve their experience when interacting with  Stadium applications.

I encourage all Stadium designers to start using this feature on new and existing applications.

Stadium3 Release : 3.1.1847.3997

Build 3.1.1847.3997  is available for download on Storytracker. It includes:

• Fix for issue with command editor resizing
• 'Refresh Parameters' button now works for queries with '@@'
• Fix for user controls disappearing after an upload
• New CurrentPage property on Datagrid
• New CurrentPage control property for DataGrid
• The size of all designer dialogs will be remembered
• Displays schema names for stored procedures
• Display of maintenance message during file upload - Users will not be allowed to work on an application while its sap file is being uploaded, they will instead see a screen displaying appropriate message.

See 'How to remember page of grid' post to see how to use new CurrentPage properties.

Stadium3 Release : 3.1.1831.3950

Build 3.1.1831.3950  is available for download on Storytracker. It includes:

• Application has new FilePath property in designer, indicates location of sap file
• DetailsView - ReadOnly property can be set to value of a custom setting, page parameter
• DetailsView - ReadOnly property can be set to true/false based on conditions. Conditions can be based on values of field, page parameters, custom settings or system variables
• DataGrid - ReadOnly property can be set to value of a custom setting, page parameter
• DataGrid - ReadOnly property can be set to true/false based on conditions. Conditions can be based on values of field, page parameters, custom settings or system variables
• DetailsView - New event for dropdowns when selection is changed
• SetControlProperties action can now be used to set DetailsView fields to be read only
• New merge warnings dialog to highlight differences between master and source files
• Merge folder structure displays new and modified files in serparate views
• Displays more informative error message when there are errors in CallLinxProcess action
• Controls can be copied from user control to a page
• Specify custom setting for Path property in Image column of grid
• Fix for high memory usage when exporting to Excel
• Fix in command editor for RefreshParameters error when query had tabs
• Fix for issue with funny characters when exporting to Excel
• Improved performance of sap file upload

Please take note:

• All sap files will have to be first loaded in designer to upgrade to latest format

A new look for Stadium

One of the things that impacts people's experience of a piece of software is the product's appearance. In fact, a lot of studies have shown that people tend to think that beautiful things work better.

We think that Stadium's output deserves a bit of love in this regard and we've been working on a couple of skins for future releases. Take a look at these and let us know what you think.

Simple blue

Inside the Stadium

Minimal black

Shiny black

My Joburg visit in May

I had the opportunity to meet Digiata’s Joburg system analysts/implementers on May 11^th and 12^th.  They are the primary users of Stadium’s designer.

The purpose of the visit was to:

• Follow up on the survey conducted earlier on in the year
• Understand pain/frustration points
• Obtain feedback to incorporate into Stadium's roadmap
• Get to see my colleagues in their "native" habitat
• Last but not least meet my colleagues in person, many of whom I have communicated with emails for a long time 

It was an awesome experience that I will never forget. It was so special to see Stadium designer open on a few desktops, and it hit me that Stadium is
for implementers what Visual Studio is for developers. It is obvious, but you really need to see to believe.

Stadium is used to create quite a variety of web applications at our clients, so received quite a wide range of requests from the various teams. Just goes to
show what a versatile and generic product it is. However there were also some common requests.

A big thanks to all the contributors and the time you invested in preparing for it. I received lots of valuable feedback,
which I will be working on during this week to come up with an updated roadmap. Watch this space for further details.

Aside from that, Joburg weather was great, much warmer than Cape Town. Also was great to see agapanthus and
iceberg roses in full bloom, you won’t see this in Cape Town at this time of the year. And enjoyed my first ride on the Gautrain
from Sandton to the airport, was great!

Stadium3 Release : 3.1.1768.3786

Build 3.1.1768.3786  is available for download on Storytracker. It includes:

• Bug fix for opening of mht files
• Bug fix for user names with special characters 
• OpenFile action has new DisplayFileDowloadDialog property - If set to true, file download dialog will always be displayed when opening the file
• ImageViewer control has new AllowPaging paging - If set to false, it will not display paging controls
• ReportViewer control has new parameters property - Can be used to pass values to report parameters
• Third party login functionality - This allows clients to authenticate users using their own internal mechanism by implementing a standard Stadium interface
• Added functionality to force a first time user to change password

Merge feature explained

Purpose: Allow more than one person to design for the same Stadium application at the same time

Scenario:

Okay, so you are at this major corporate and an application on Stadium3 has just gone live. However you still have to add new pages, make changes for the next version of the same application and you have a team of six implementers.  There is a lot of work to do and all the six implementers need to start implementing the changes, there is one set of files i.e. sap and config file for the application. How do you do this?

Definitions:

Master file: The Stadium application file from which merge feature will be triggered.

Source file: The Stadium application file with the changes, these changes need to be merged with the master file

How:

• The starting point is the sap and config file of the application in production, in this scenario this is the ‘master’ file.
• Each  implementer needs to copy both the master sap and config files, the copied files are the ‘source’ files
• Open the source application in the designer
• Make the necessary changes/additions and save
• When finished open the master application
• Click on Merge toolbar button on the master application
• Select the source stadium application as the file to merge
• The merge dialog will highlight the new/modified entities
• Select the entities you have changed
• Save the changes
• Notify the rest of the team you have updated the master file
• Each team member now needs to update his/her application file with the changed master file. In this scenario each member’s file becomes the master file and the master file the source file.

Please follow below suggested best practices:

• All components should be named as per their function e.g. if a page displays a list of users, give it a name to indicate the same, do not keep the default name e.g.’ Page10’
• After merging the changes with the master application, let other team members know that it has been updated. It is ideal that they merge the changes with their local sap files as soon as possible. This way the changes are kept minimal and there is less likelihood of clashes occurring.
• A page is regarded as the smallest unit of work. If two implementers work on the same page, only changes made by one of them can be maintained. It will best to split the work on a page by page basis.
• If an entity is deleted in the master file and not in the source file, when merging, it will appear as a new file as this entity does not exist on the master file.  It will be best deletes are communicated to team members.

Stadium3 survey results

Results of Stadium3 survey can be found at below link:
http://stadium3.files.wordpress.com/2011/02/stadium3survey.docx

Thanks to all the participants.

Stadium3 Release : 3.1.1745.3738

Build 3.1.1745.3738, first release in 2011  is available for download on Storytracker. It includes:

• Improved performance significantly
• Fixed large number of concurrent user issues
• New DisplayHeader property for filter
• Fixed IE6 issue with display of filters and menus
• Fixed IE6 issue with user login name disappearing
• Integrates with latest version of Linx