Table of Contents
ARLSS.NET 2005 Version History
ARLSS.NET 2005 version 1.2.0.10 May 31, 2006 2
ARLSS.NET 2005 version 1.2.0.11 June 5, 2006 7
ARLSS.NET 2005 version 1.2.0.12 June 6, 2006 8
ARLSS.NET 2005 version 1.2.0.13 June 12, 2006 8
ARLSS.NET 2005 version 1.2.0.14 June 15, 2006 8
ARLSS.NET 2005 version 1.3.0.0 September 13, 2006 9
ARLSS.NET 2005 version 1.3.0.1 September 18, 2006 12
ARLSS.NET 2005 version 1.3.0.2 September 20, 2006 13
ARLSS.NET 2005 version 1.3.0.3 September 25, 2006 13
ARLSS.NET 2005 version 1.3.0.4 September 26, 2006 13
ARLSS.NET 2005 version 1.3.0.5 September 27, 2006 14
ARLSS.NET 2005 version 1.3.0.6 October, 12 2006 14
ARLSS.NET 2005 version 1.3.0.7 March 21, 2007 15
ARLSS.NET 2005 version 1.3.0.8 March 21, 2007 16
ARLSS.NET 2005 version 1.3.0.9 May 2, 2007 17
ARLSS.NET 2005 version 1.3.0.10 May 16, 2007 17
ARLSS.NET 2005 version 1.3.0.11 January 31, 2008 20
ARLSS.NET 2005 version 1.3.0.12 June 16, 2008 21
ARLSS.NET 2005 version 2.0.0.0 August 26, 2008 22
ARLSS.NET 2008 version 3.5.0.5 February 3, 2010 23
ARLSS.NET 2008 version 3.5.0.6 April 27, 2010 25
ARLSS.NET 2008 version 3.5.0.7 April 27, 2010 25
ARLSS.NET 2008 version 3.5.0.8 May 4, 2010 25
ARLSS.NET 2008 version 3.5.0.9 January 11, 2011 26
ARLSS.NET 2008 version 3.5.1.0 February 15, 2011 26
ARLSS.NET 2008 version 3.5.1.1 – Fix Dates March 22, 2012 26
ARLSS.NET 2008 version 4.0.0.0 – IT Security & USFWS July 24, 2013 30
ARLSS.NET v2016.01 – Seasons Filter May 16, 2016 31
Proposed #1: Push new schema 32
Proposed #2 : Workflow analysis 32
ARLSS.NET 2005 version 1.2.0.10 May 31, 2006
The ARLSS.NET client application and webservice have been completely reworked and tested. The new functionality and features will be described in this memo.
The major revisions to this version are:
· Conversion to .NET 2.0 Framework
· Scope field for grants has been added
A scope field has been added for grants. Multiple scopes may be added to a grant and the latest grant shows when entering the form.
· Removal of conflict resolution and data caching
The purpose is to increase speed and reliability of the application. As conflict resolution has been removed, all data is entered into the database according to a last-in-wins strategy. As all ARLSS editors and readers have access to high-speed connections, data caching has been removed. For my connection, it takes just over half a minute to download the entire dataset currently at a size of 17.5 MB. To keep current with the live database, the user should synchronize regularly to get the latest, most current data from the database
· Click Once deployment
· Optimized data access
The webservice has been completely revised for better performance by conversion of all data access to use stored procedures. This conversion alone required code review and testing for the entire webservice and client application.
.
The entire application (client and webservice) has been converted to the .NET 2.0 Framework using Visual Studio .NET 2005. This latest version of the development environment and framework offer some great advantages as follows:
1. Click Once Deployment – This feature greatly simplifies deployment and installation of the ARLSS.NET client application.
a. The user may easily install the entire application from the web server at https://services.denver.veco.com/ARLSSInstall/Publish.htm. All required prerequisites and the application itself is installed on the user’s computer from the “INSTALL” link on this page.
b. The application is installed on the user’s machine and a link is installed in the user’s StartàAll ProgramsàVECOàARLSS.NET 2005 menu item.
c. The program may be removed from Add/Remove Programs.
d. As new updates are deployed to the server and made available, the user is automatically prompted to install the new version upon opening the ARLSS application.
Figure 1 – New version of ARLSS is available dialog
2. Timeouts seem to be solved in this version of the .NET Framework – The greatest problem with the previous versions of ARLSS, and the greatest source of data inconsistencies has been associated with sporadic, and sometimes regular, timeouts during uploading of data to the webservice. These timeouts were the greatest source of errors for the conflict resolution system. Many workarounds were tried to overcome this problem, but workarounds are never any good. The .NET 2.0 Framework provides other transport methods. We were considering upgrading to this version of the Framework such that we might utilize some of these other transport methods to hopefully, overcome the timeout problem. However, it appears that the webservice data upload process has finally been solved and made reliable in this version of the .NET Framework. I have not encountered a single timeout during my testing. Additionally, I set up an automated test that uploaded data to the webservice 1000 times over a 5-hour period. And the process did not timeout once. I am very hopeful that this problem has been solved, and that the users of this application will never again see a timeout.
a. I have even included some defensive coding in this application to allow the user to receive a return message from the webservice (recommended), or simply submit without any expectation of a return (not recommended). A checkbox labeled “webservice messages” as shown in Figure2 allows the user this choice. In the example that follows, we will describe why a return message from the webservice is important:
i. In this example, I set up a test case to cause a “UNIQUE KEY constraint” error in the database. I set up the client dataset and central database such that there is a grant with proposal number “VPBarrow” in the database, but not in the client dataset. In this scenario, the user will try to submit a grant with proposal number “VPBarrow” as a new grant record. The database includes a uniqueness constraint that assures that all grants have a unique proposal number.
ii. Upon submission to the webservice, the message returned from the webservice lets the user know that this record could not be submitted, as there already exists a grant in the database with proposal number “VPBarrow”. At the same time, the “Synch” button is turned red, as a SYNCH IS REQUIRED to get the client’s data in synch with the central database.
iii. If the user had unchecked the “webservice messages” and submitted to the webservice, the user would not know that his/her updates ever made it to the database nor, as in this case, that the “VPBarrow” record could not be submitted to the database due to database constraints. It would be much more critical in this scenario, that the user SYNCH regularly and look to see that his/her updates made it to the database.
iv. I have however, left the choice to the user in the horrible case that timeouts ever become a problem again.
The application has been fully tested. Messaging from the webservice has been optimized to help the user understand why his/her data could not be submitted in the case of data errors such as:
· Primary Key violations
· Unique Key violations
· Foreign Key violations
· Attempt to Edit a Deleted Record
· Attempt to Delete a Deleted Record
· Other Database Errors…
All fields for the record that failed to submit are shown in the webservice message textbox to assist the user in determining which record failed.
The total number of potential errors is greatly reduced from previous versions, as there is no conflict resolution. Any errors that are returned are errors that violate database constraints and should be noted and understood by the ARLSS editor.
In cases wherein the user’s data is known to be out-of-synch with the central database, the SYNCH button is highlighted by turning red on the DB Update Form.
Figure 2 – New functionality on Update Database Form
Installing ARLSS.NET 2005
The following printscreens will show you what you will see when installing the application.
1. Open a browser and navigate to https://services.denver.veco.com/ARLSSInstall/Publish.htm
2. Click “Install”
3. You will get the following security warning dialog box.
4. Click “Install”
5. The installer will check whether you have the .NET 2.0 Framework installed on your computer. If not, it will provide a dialog to allow you to install this Framework.
6. Depending on any firewalls or spyware filters that you have on your machine, you may get other warning dialogs. For this application, always choose to give this application full trust and access when prompted by any such dialogs. This application needs to be able to write data to your system, for your local, disconnected copy of the ARLSS database.
7. You will get a progress screen as the application downloads and installs.
8. Then, the application will startup and ask you to login to the webservice for authentication.
9. Login and begin using ARLSS.NET 2005. Always select the “Live” webservice that comes as default in the option selection box.
ARLSS.NET 2005 version 1.2.0.11 June 5, 2006
The following modifications were made for this version:
1. The user’s dataset named ARLSSdata.xml is stored for each user on their machine in a directory named c:\ARLSSdata. (The entire path to the dataset being “C:\ARLSSdata\ARLSSdata.xml”). This is done to simplify and standardize the connection of the external Access database used by some ARLSS users to query and analyze the data in the xml datset. (Previously, this file was stored deep in the user’s document and settings directory under a unique path for each user. Thus making it very difficult to map the dataset to the Access database).
2. A Version Notes link label was added to the main form of the application that links to this ReleaseNotes.doc file. Each release will be documented in this file.
ARLSS.NET 2005 version 1.2.0.12 June 6, 2006
The following modifications were made for this version:
- The maintenance buttons were fixed. In the previous version the Address, Data, Location, and Code Maintenance buttons failed to open their respective forms. This has been fixed in this version.
ARLSS.NET 2005 version 1.2.0.13 June 12, 2006
The objects that load an instance of an Internet Explorer browser have been fixed. This fixes the following items in the client application:
1. The spell checker
2. Clicking on email address or website on PersonEmail/PersonWebsite entry grids to open a browser to the selected location.
ARLSS.NET 2005 version 1.2.0.14 June 15, 2006
The following modifications were made for this version:
1. A correction has been made to the central data entry control wherein the dropdown would be left as blank after attempting to type in a selection. This problem was reported by Angela and is listed as Issue# 140 in the Issue Manager at https://services.denver.veco.com/IssueManager. This problem has been fixed.
2. After taking another look at how this new application works, the application has been opened up to allow deleting a record after inserting a record in the client application. Previously, the record would require submission to the database before allowing deletion in the client. This was due to some previous error messaging that is no longer relevant for this new application.
ARLSS.NET 2005 version 1.3.0.0 September 13, 2006
In this version, the ARLSS.NET application has been modified for IPY fields (International Polar Year). The following has been modified for this version:
1. Grant Form:
a. A checkbox has been added on the Grant Form to signify that the grant is an IPY project.
b. A new IPY address type has been added such that the IPY website address may be added on the GrantWebsite tab of the Grant Form.
c. A new tab named “Discipline” has been added to add multiple Disciplines to a grant.
2. New Discipline Codes – hierarchical data structure administered using a TreeView and data added by dropdown on the new Discipline tab of the Grant Form (see 1.c. above). The dropdown will show the Discipline data in the form of a path such as: IPY\XYZ\ABC…
a. New Discipline Maint Form includes a TreeView to add/edit and delete the new Discipline codes.
3. New Program Codes – hierarchical data structure administered using a TreeView and data added by dropdown on Grant Form. The dropdown will show the ProgramCode data in the form of a path such as: NSF\ARCSS\SCE\…
a. New Program Maint Form includes a TreeView to add/edit and delete the new Program codes. This replaces the SciProgramCode field that was previously added at the grant level.
(example showing new TreeView control to administer ProgramCode data)
4. A new field called LocationType has been added to the Location table. The user may add LocationType data to a Location by typing in or selecting existing LocationTypes from the dropdown on the Location Maint Form. New LocationTypes may be added to the list if the data does not currently exist in the list. If a new LocationType is entered in the dropdown, the user will be prompted that this is a new LocationType and the user will be asked whether or not to add it to the list of LocationTypes.
Other enhancements:
A. Allow the user the opportunity to save or cancel data edits on leaving either a data grid control or a form wherein the user has not yet submitted the new data.
a. When the user enters data into any of the grid controls and leaves the control, they will be prompted that they have pending data changes. They are offered the opportunity to submit the data or cancel the new data.
(In this example, I added a new Person and Role to the PersonGrant control grid, then clicked on the Season Tab. The messagebox gives me a chance to submit the new record by selecting “No” or canceling the new record by clicking “Yes”.)
b. When the user enters data into any form and leaves that form without submitting the new data, a similar message will pop-up to allow the user to either go ahead and submit the new data or cancel the new data.