After many years of using Dream version 2.10 Jarvis Hotels Limited have upgraded to the latest version. Late in the evening of Friday 13th July Sorsis swung into action and began the process of upgrading the live database. By Sunday afternoon the database had been transferred to the new SQL Server 2005 server, split into two and both parts upgraded to Dream 3.3.
One of the new databases contained two full years of historical data plus the current year (the live database) and the other database contained the previous eight years. By Monday lunchtime most of the key users were entering information into the live database again.
In addition to the switch to SQL 2005 Jarvis also moved from using SQL Server logins to Windows Authentication. This was possible because of the long user name functionality added to the User table, that enabled the mapping of the users existing Windows User names to their existing Dream User ID.
The old live database had grown to 18Gb in Dream 2.10. With the additional tables in Dream 3.3 it would only have increased during the upgrade, so it was decided to split the database into a Live database and an Archive database. The new Live database is a more manageable 5Gb, and the Archive database is still available to all users in Dream 3.3.
After the decision split the database some of the bought ledger staff expressed concern about duplicate invoices. In order to allay these fears Sorsis came up with a Virtual Entity based on a view drawing information from the Archive database. The resulting lookup function on the Purchase Invoice UDI warns the user if there is at least one potential duplicate in the Archive database, and gives them the DocType/Docnum combination of the first potential duplicate that it finds.
The old report column that displays an asterisk against a row warning of a comment attached to the detail no longer works in Dream 3.3. Sorsis replaced this functionality with a Custom Column based on a Lookup Function running against a fake Document Detail Entity. Why use a fake Document Detail Entity? A Virtual Entity with a lookup function would be the obvious choice, except that the Nominal Detail and Account Reports provide neither the Row Number or Refno fields so it would be very difficult to isolate the correct detail row. However, the @DOCUMENTDETAIL lookup function, used to retrieve Document Detail Entity information will isolate the correct row.
It was then a question of creating the Entity and replacing it with an appropriate view.
One of the big gains for the Head Office staff has been the ability to run a Hotel P&L with Actuals, Budgets and Variances directly in Dream. This had previously not been possible because each Hotel was an Account in a Ledger against the P&L Nominals and Dream 2.10 did not have the Ledger Balance Report.
The changes to the input forms in Dream 3.3 meant that the forms needed major surgery. Sorsis took the opportunity to rationalise the forms and managed to get the number down from 289 in the old database to 19 in the new database. The new forms were created in a range of, what were thought to be, inoffensive pastel shades. It appears that, indeed, you cannot please all of the people all of the time.
Most of the existing reports had been migrated and tested before the upgrade. The move to Windows Authentication and the fact that some users access the system through Terminal Services made some testing more of a challenge than it would otherwise have been. In some cases it was a few days before the tools or reports were used, so there was a period of a few days when the odd issue had to be tackled.
Overall the upgrade went according to plan, with users experiencing relatively little disruption.