Build 6005 - Issues and Workarounds
I completed our upgrade to Build 6005 today from Build 6000, and I wanted to share some issues that arose and my workarounds.
Mail Fetching:
The username field was changed to server\\username from server\username. This prevented the mail fetching function.
Workaround: Remove the extra "\"
Notification Templates Destroyed:
After the upgrade all of our Notification Templates contained something like "net.sourceforge.jtds.jdbc.ClobImpl@1ded4c9" which I recognize as a Java serialization of an object. In layman's terms it a bug; it's trying to cram an object, like a document or workbook, into a text field.
Workaround: Luckily, we only use 4 of these templates, so I simply composed new templates and saved them. A minor annoyance for us, but this could be a big annoyance for a company who uses all of the templates.
Upgrade Process Failure On MS SQL Server:
We were using Build 6000 running on MS SQL Server. I tried do the upgrade from Build 6000 to Build 6005 on a test server, and it failed several times due to some issues with changes to fields and tables.
Workaround:If you're not a tech person, I don't recommend that you try this; try SD+ support instead. If you have any doubts don't proceed. I am not an SD+ support person. As long as you back up your data, you can recover it.
The idea is to use MySQL to upgrade to 6005, then convert to MS SQL Server, however, you must include your current data in that upgrade.
1 ) Back up your data using the SD+ Backup Utility
2 ) Copy that backup file to somewhere safe, I recommend copying the entire backup directory somewhere safe because of step 4
3 ) Uninstall SD+
4 ) Delete the entire Adventnet directory. This removes any update history.
5 ) Install SD+, making sure to select MySQL for the database
Method A) If you have not upgraded from the initial install, then re-use that install file. It's build number must match the build number on the data you just backed up.
Method B) Otherwise, use the install file for the highest build below the build you were using. We were using build 6000, so I installed a 500X build, started and stopped the SD+ server, then ran the UpdateManager and upgraded to build 6000 (to match our data's build)
6 ) Start and stop the server. So using either Method A or B, we now have a build that's using MySQL that matches our current data's build (what's on production server) and the MySQL database is empty. Yes? OK, step 7
7 ) Use the RestoreData utility to pull in the data backup you made in step 1 (your current production data). I hope you remembered to move it before you deleted the directories in Step 4. You now have essentially the same as you did before we started this, except that you're using MySQL. Start the server and check your data, if all is good then stop the server.
8 ) Back up your data using the SD+ Backup Utility
9 ) Now use UpdateManager to apply the build 6005 Service Pack. If you have any problems now, you'll need to talk to SD+ Support or check the forums again. I had no issues; I hope you don't either.
Start the server and check your data, if all is good then stop the server.
10 ) Back up your data using the SD+ Backup Utility (Very Important!!!)
11 ) You now have the build you want, 6005, running your data, the last thing is to move back to MS SQL Server, which you've probably done already if you were using it before. Run the ChangeDBServer utility and select MS SQL Server and enter your parameters. Use the Test to make sure you're connected again. There is documentation elsewhere on how to do this.
12 ) Deep breath, last step. We now have Build 6005 running on a blank MS SQL Server database. One last time run the RestoreData utility. Start the server and check your data. If all looks good, have a drink, you're done! You might want to check your templates in case they got over-written like mine (see above)
I hope this helps someone out! It took me a while to work out how to complete this upgrade, but I'm glad that I did as there are many worthwhile bug fixes included.
Mail Fetching:
The username field was changed to server\\username from server\username. This prevented the mail fetching function.
Workaround: Remove the extra "\"
Notification Templates Destroyed:
After the upgrade all of our Notification Templates contained something like "net.sourceforge.jtds.jdbc.ClobImpl@1ded4c9" which I recognize as a Java serialization of an object. In layman's terms it a bug; it's trying to cram an object, like a document or workbook, into a text field.
Workaround: Luckily, we only use 4 of these templates, so I simply composed new templates and saved them. A minor annoyance for us, but this could be a big annoyance for a company who uses all of the templates.
Upgrade Process Failure On MS SQL Server:
We were using Build 6000 running on MS SQL Server. I tried do the upgrade from Build 6000 to Build 6005 on a test server, and it failed several times due to some issues with changes to fields and tables.
Workaround:If you're not a tech person, I don't recommend that you try this; try SD+ support instead. If you have any doubts don't proceed. I am not an SD+ support person. As long as you back up your data, you can recover it.
The idea is to use MySQL to upgrade to 6005, then convert to MS SQL Server, however, you must include your current data in that upgrade.
1 ) Back up your data using the SD+ Backup Utility
2 ) Copy that backup file to somewhere safe, I recommend copying the entire backup directory somewhere safe because of step 4
3 ) Uninstall SD+
4 ) Delete the entire Adventnet directory. This removes any update history.
5 ) Install SD+, making sure to select MySQL for the database
Method A) If you have not upgraded from the initial install, then re-use that install file. It's build number must match the build number on the data you just backed up.
Method B) Otherwise, use the install file for the highest build below the build you were using. We were using build 6000, so I installed a 500X build, started and stopped the SD+ server, then ran the UpdateManager and upgraded to build 6000 (to match our data's build)
6 ) Start and stop the server. So using either Method A or B, we now have a build that's using MySQL that matches our current data's build (what's on production server) and the MySQL database is empty. Yes? OK, step 7
7 ) Use the RestoreData utility to pull in the data backup you made in step 1 (your current production data). I hope you remembered to move it before you deleted the directories in Step 4. You now have essentially the same as you did before we started this, except that you're using MySQL. Start the server and check your data, if all is good then stop the server.
8 ) Back up your data using the SD+ Backup Utility
9 ) Now use UpdateManager to apply the build 6005 Service Pack. If you have any problems now, you'll need to talk to SD+ Support or check the forums again. I had no issues; I hope you don't either.
Start the server and check your data, if all is good then stop the server. 10 ) Back up your data using the SD+ Backup Utility (Very Important!!!)
11 ) You now have the build you want, 6005, running your data, the last thing is to move back to MS SQL Server, which you've probably done already if you were using it before. Run the ChangeDBServer utility and select MS SQL Server and enter your parameters. Use the Test to make sure you're connected again. There is documentation elsewhere on how to do this.
12 ) Deep breath, last step. We now have Build 6005 running on a blank MS SQL Server database. One last time run the RestoreData utility. Start the server and check your data. If all looks good, have a drink, you're done! You might want to check your templates in case they got over-written like mine (see above)
I hope this helps someone out! It took me a while to work out how to complete this upgrade, but I'm glad that I did as there are many worthwhile bug fixes included.