When upgrading CAREWare there are a few considerations to keep in mind.

 

• Managing server related issues in preparation for a CAREWare upgrade
• The length of time it takes to upgrade CAREWare and therefore how long CAREWare is inaccessible to users.
• Error messages during the upgrade process and best ways to resolve them
• What to do if the CAREWare upgrade completes, however CAREWare is not working now.
• What to do if data appears to be missing after upgrading CAREWare.

 

Managing CAREWare Server issues

 

JPROG, the company that creates CAREWare, recommends agencies that install CAREWare on a server, use the latest version of SQL Server and Windows Server and have the lastest Windows updates installed to maintain a secure server. For CAREWare to work correctly, Message Queuing and .NET Framework 4.8 need to be installed on the server the CAREWare Business Tier is on. The CAREWare Help Desk is available to assist with issues with CAREWare, however it is expected that the local server is managed by the hosting agency, which includes installing, maintaining, and updating these Windows applications.

 

Issues that may arise otherwise:

 

• The CAREWare Business Tier service fails to start. In this case the .NET Framework needs to be updated to 4.8, the 4.8 components need to be enabled, and/or Windows updates need to be completed to include .NET related updates.
• An old Bcrypt.dll file is in the CAREWare Business Tier folder and needs to be deleted. Click here for instructions to resovle.
• CAREWare failed to connect to the database. Click here for instructions to resolve.
• Some other Windows related error. It may be necessary to check the Windows Event Viewer to learn more about those errors.

 

Understanding the length of time for upgrading CAREWare

 

When upgrading CAREWare, it is important to understand the complexity of the upgrade process and the factors that play a role in that process. When the CAREWare Business Tier is upgraded, the first thing CAREWare does is try to connect to the database and complete a version check. CAREWare is verifying the database was operating with an older version of the CAREWare Business Tier so CAREWare can figure out which updates are required. CAREWare then completes a data tier update until the data tier version matches the installed version of CAREWare. That process can take minutes to hours to complete.

 

Here are some factors to consider regarding the length of time it takes to upgrade CAREWare:

 

• The size of the database. Larger databases may have more data points to update or change during the upgrade process. Larger databases may have more CAREWare features enabled which can affect how many different updates or what types of updates need to be run.
• The number of clients the providers serve. Some data tier updates make changes to client level data. If there are a lot of clients, it can take longer to make those changes. An example of this would be when CAREWare updated the encryption algorithm and all encrypted data needed to be decrypted and then encrypted again. Providers with a lot of clients needed more time for the update to complete.
• The number of features users have enabled in CAREWare. CAREWare is running the data tier update for the cw_data database, which includes client level data. CAREWare has features that create other databases such as the cw_pdi (for SQL imports/exports), cw_attachments (for attaching documents), and cw_user_action (for tracking user activity). The more features that are enabled, the more databases that need updates and the greater the complexity for the update process.
• The hardware and software of the CAREWare server. Like any software that needs to be updated, the performance of the CAREWare upgrade is confined to the processor power, RAM, version of Windows Server, version of SQL server, and other install applications or updates on the server that can impact the performance of the server. If the CAREWare database is installed on a separate server from the CAREWare Business Tier, that can offer more hardware resources, however add a constraint based on the bandwidth of the network.

 

Error messages that occur during an upgrade

 

When upgrading CAREWare there may be errors that occur, which can impede the completion of the upgrade or be a sign the upgrade was incomplete.

 

• An error occurring while processing the request shows up at the login screen. This indicates the CAREWare Business Tier service is stopped. Try starting the CAREWare Business Tier service in local services or by clicking Start Server in the CW Admin Utility (The CAREWare User Interface) by following the instructions here. If there is an error starting the service in Local Services or starting the server in the CW Admin Utility, refer to the instructions above under Managing CAREWare Server Issues.

 

 

 

 

• The Business Tier is initializing. This means that CAREWare started and is connecting to the CAREWare database. This is a normal message when CAREWare is working. This process can take seconds or can last several minutes depending on the factors described earlier regarding the length of time it takes for the data tier update process to complete. A larger database, more clients, or more CAREWare features means that CAREWare has more things to check when it starts. This message also appears while the data tier update process is running. Until CAREWare notes the data tier update process is done in the cw_events files, this message appears for users. Users can only log in after the data tier update process completes. The cw_events file is located in the CAREWare Business Tier folder and can be reviewed to see where CAREWare is at in the update process.

 

 

• Users are prompted to press CTRL-F5 (Cmd+Shift+R for Safari) or the username field is greyed out preventing users from logging in. Anytime CAREWare is upgraded, the first thing users need to do is press CTRL-F5 at the login screen to reload the screen and then after they log in, click Find Client and press CTRL-F5 again. This completes a hard reload refreshing the browser to use the latest version of CAREWare.

 

 

If users state they pressed CTRL-F5 and the prompt is still present, then the CAREWare HTTP Server is a different version than the CAREWare Business Tier. In this case, the CAREWare Business Tier is build 223 and the CAREWare HTTP Server is build 186e. The CAREWare Business Tier and CAREWare HTTP Server need to be installed using the installation files for the same build by following the instructions here.

 

 

 

 

• Users can log into CAREWare, however the Add Client/Find Client buttons are not working. It may be that users need to press CTRL-F5 (Cmn+Shift+R for Safari) and maybe there wasn’t a prompt. Users could try a different browser. Users should make sure the browser they are using is updated to the latest version. Users should use any browser, including Safari, other than Internet Explorer. If the browser is the correct type, updated, and refreshed, the user should verify that pop up blocking is disabled for the CAREWare website. If pop-up blocking is disabled, then the CAREWare HTTP Server service should be restarted in Local Services on the CAREWare server. If the Add Client/Find Client screen is still not working or there is an error that users are disconnected, the CAREWare HTTP Server should be reinstalled making sure to use the correct build of that application.

 

CAREWare was upgraded, however it is now not working:

 

There can be a lot of potential issues reported by users after an upgrade where users state some aspect of CAREWare is no longer working after an upgrade.

 

• In some cases, users are reporting an error message using a feature in CAREWare, where they weren’t getting errors before. Users should get an error code or a pop up message with an error that includes the time of the error. That error code or error time can be used to review the error details in the System Log, by following the instructions here. If the issue in the error details could not be located on our FAQ page here and the issue does not appear as a reported bug here, the error code/time and the system log should be emailed the the CAREWare Help Desk for review by following the instructions here.
• In some cases, the CAREWare Business Tier and CAREWare HTTP Servers were upgraded to the correct build, however there is a different error than those listed above at the log in screen and restarting the services did not resolve the issue. This could mean the data tier update failed to complete. In that case, email the cw_events to the CAREWare Help Desk for review. Data tier updates can be complicated and the logged messages may be best reviewed by a JPROG programmer to ensure the update is complete. The cw_events file includes the date when CAREWare was upgraded and is located in the CAREWare Business Tier folder located at C:\\Program Files\CAREWare Business Tier by default. In most cases, data tier updates that fail can be resolved by changing the datatierversion number or updatetorun number in the Common Storage Settings of the database or in the CW Admin Utility of the CAREWare Business Tier. It is important to make sure that all updates complete, so refrain from changing those numbers to match the final datatierversion number to complete the update. The data tier update process needs to be allowed to complete and in some cases the update process involves re-running older updates that failed to complete. The data tier update process is logged in the cw_events and can be viewed in CAREWare in the System Log.
• In some cases, processes like imports and exports change from build to build. Users report that imports/exports are no longer working after CAREWare was upgraded or automatically imported data appear to be missing. In some cases, there are bugs that need to be fixed. In other cases, there are changes to how CAREWare functions in regards to those imports and exports. Examples of these changes in function are the changes to importing/exporting custom fields in the RSR build 171, adding the automatic imports subfolder to the PDI Files folder for automatic imports, and needing to zip MDB files in the RSR build 214. The bugs and the changes to the application can be reviewed in the Version History page here. In cases, where a bug isn’t listed or a change in function isn’t mentioned in the Version History, users can always contact the CAREWare Help Desk to discuss those bugs/changes by following the instructions here.

 

CAREWare was upgraded and now data is missing

 

After upgrading some users have reported that records, custom fields, or settings are changed or missing. This is an issue that JPROG works to prevent in any build. Ideally CAREWare settings and data entered in prior builds are retained at all times. If a user cannot find a client, clients appear to be missing services, or custom fields can no longer be seen, then this is likely due to a bug or a change in how CAREWare is handling those records.

 

• An example of the custom field visibility issue would be in build 214, there was a bug where custom referral fields were not visible. That bug needed to be fixed in a newer build.

 

• An example of users being unable to find some clients after upgrading, was caused by CAREWare failing to generate cw_client_custom field records for that client for that provider, which resulted in the client missing in Find Client results. That issue was also fixed in a newer build.

 

• An example of users reporting services missing for clients, would be cases where the sorting of the service table changed and users needed to resort the list by date to see recent services.

 

In other cases, users have expressed concern that records are missing or have changed since the upgrade. The best scenario to prevent possible data loss would be to have a separate server with CAREWare installed to test new builds before installing a new build on the CAREWAre server with real client data. Having a test server can also provide an option ot use a new build for completing reports like the RSR, while waiting for a critical fix. In cases like that, a proivder may choose to keep their production CAREWare server using the older build waiting for the fix and use the test server with the latest build installed to run reports. The tets server would just have to have the latest data set from production to run those reports.

 

Lacking a test server, the next best option to retrieve those records or to get the correct record, would be to recover those records from a backup of the CAREWare database. This means that there should always be a backup of CAREWare prior to upgrading. That backup file should be available at the time of the upgrade so that CAREWare can be rolled back to the earlier build in the case of actual data loss or be available so that the records can be exported from the backup and imported to the new build. To export records from a backup, there needs to be a second separate CAREWare server setup or the process can become quite time consuming and complex.

 

Here are instructions for managing and maintaining backups in CAREWare.

 

The steps outlined in that user guide work for maintaining CAREWare backups in the system, however are inaccessible in the case where CAREWare isn’t working. If a data tier update failed, then the CAREWare Business Tier service is stopped and users cannot log in to access those settings. In addition, CAREWare can only be restored outside of the application if the service is stopped. Understanding those limitations, users who upgrade CAREWare should have working knowledge of SQL Server Database Instances and SQL Server Management Studio as that is the database application CAREWare uses to store that data and that application is the only way to create backups and restore the database while CAREWare is down.

 

Here are instructions from Microsoft regarding managing and maintaining backups.

 

Here are instructions from Microsoft regarding restoring a database from a backup.

 

In relation to CAREWare and how restoring CAREWare to an earlier backup would affect CAREWare, here are some things to consider:

 

• The earlier backup file has an earlier datatierversion number. Connecting the currently installed CAREWare Business Tier to that backup would trigger the data tier update process to occur again. With that in mind consider what was stated earlier about the timeframe it takes to complete that update process. If the backup was taken while CAREWare build 171 was installed and build 223 is currently installed, CAREWare will update the database to the version of build 223 as soon as the CAREWare Business Tier service starts and it connects to the database.
• In order to install an earlier build of CAREWare, in this case build 171, build 223 has to be uninstalled in Programs. The build 171 installation file will fail as the setup wizard recognizes a newer build is already installed.
• If the build 171 installation file is run prior to restoring the database, an error will appear that the business tier that was run is an earlier version than the database it is connecting to. This message is logged in the cw_events in the CAREWare Business Tier folder. In order to install the earlier build, the database needs to be restored using a backup from that build or earlier.
• Anytime the database is restored, the CAREWare Business Tier service needs to be stopped first. SQL locks databases from restoring any time processes are accessing that database. In most cases, the SQL Server Database Instance needs to be restarted in addition to stopping the CAREWare Business Tier service before a restore can occur.
• After restoring the database and prior to starting the CAREWare Business Tier or installing the preferred build of CAREWare, make sure to set the CAREWare Business Tier login as the database owner by running the following query.

 

Exec sp_changedbowner ’cwbt‘

 

This sets the CAREWare Business Tier login as the database owner and allows the database connection to complete when the CAREWare Business Tier service is started.

 

When considering rolling CAREWare back to an earlier build, it is recommended to do so with the advice of JPROG programmers. There are a lot of things to consider when installing CAREWare, a lot of complex issues that can arise, and in most cases these issues can be resolved using the latest version of the software and maybe a bit of effort from JPROG programmers to fix the issue. If CAREWare is rolled back prior to getting that support, it is possible that some of the information regarding the issue may be lost and JPROG programmers would no longer have that information to work out a solution or fix for the problem. It is understandable that a program may choose to roll CAREWare back to an earlier build to get CAREWare up and running for their users while they wait to get support from the CAREWare Help Desk or JPROG. In those cases, please retain the cw_events files for the day before the upgrade, the day of the upgrade, and the day the issue was reported by users. CAREWare only retains cw_events files for 5 days based on the default settings. So it may be the case that the log of the error messages are lost over the weekend while waiting to get support. Please archive those files in a separate folder or email them to the CAREWare Help Desk to get to the programmers.