![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
I'm trying to upgrade and migrate a crucial rostering system at work - did I mention I'm not just the email administrator any more? no, I do lots of things now - and it's been a pile of fun.
To install a new version of the software, we need to install the old one and then run an upgrade - there is no new install package at all. The old version is written in some ancient version of VB - I suspect VB4 - and requires you to do fun things like manually registering OCX files, installing services by hand, and editing both INI files and the Registry. It uses DEX for the rules calculation stuff... a product that was initially developed in the early-90s, I believe. The data is stored in an SQL database, which is fine other than the quaint way the middleware component wants to write stored procedures to the master db on the server, not just its own db. Writing things to the master db is really not that desirable when a server is hosting literally dozens of databases. What happens if some other db decides to call its stored procs the same name and store those in master as well? Just ridiculous.
We got it up and running after quite a bit of angst with replicating the old server's installation of the middleware, and restoring a copy of the old database from backup to the new SQL server, albeit with a different name. After running a few simple tests from a client, we then tried to run a crucial import procedure that picks up personnel data from SAP. The middleware component connects to a drive where SAP has dropped its data (by means of a quaint batch file), and also to its own database, and then runs a compiled executable (nothing so transparent as a script to process the data, because then we might see what it's doing) and some of the stored database procedures to jam the SAP stuff into the database. Now, getting the thing connected to its own database on a remote server was fun anyway - after we sorted out the master db malarkey - because it requires you to configure an ODBC connection to the new database on the middleware server AND run the middleware client once and configure the new connection information again, which it drops into the dreaded INI file.
Our import kept failing at the point just before it updated the data into the database. I got the ODBC tool logging the SQL output passing through it, and found that it referenced the OLD database connection information about 10,000 lines through the import job... just before the failure. Now, remember that it had read the ODBC connection information and the INI file to connect to its database to do the stored procedures and various queries for processing the data -- when it came time to jam the information back in, guess where it was reading the connection information from? No, not the ODBC. No, not the INI file. It was reading it from a field inside the database it was already connected to.
GAHHHHHHHHHHHH!
That import connection info field happened to be configurable from inside the client (not the middleware) GUI, so we didn't have to futz around inside the database, but why why why it's even an option is totally beyond me. The clients and the middleware are only ever connected to the one database, so where on earth else would you be importing the data to? And since you can't run the import without being connected to its own database, and you can only be connected to one database at a time...? (Exporting it in a configurable way makes sense.)
And this is just trying to replicate our existing install. I am soooo waiting for the actual upgrade, which requires that we install the .NET framework on the middleware server... V2 and V3 (I mean, WTF?), and then run no less than 6 conversion scripts, two for the database and 4 for the middleware and clients. Again, they can't provide us with just a new fresh installer and perhaps a db upgrade script.
Still, we're getting there. Also on the exciting things actually working front, I have a version of Trac and Subversion installed on a Linux server to manage source control in our organisation, and it's all working great, complete with Active Directory authentication and reasonably granular directory permissions. I just now have to break the news to the SOE team that no, they cannot have a separate Trac project for each and every application they maintain. Of which they have scores. They can consider their applications as components of a SOE version. So there. Because I'm not going to sit there and twiddle with zillions of little projects constantly. The next thing is to see if we can mirror the Subversion repositories to a remote server for DR purposes (and have it update itself constantly). Eeee!
To install a new version of the software, we need to install the old one and then run an upgrade - there is no new install package at all. The old version is written in some ancient version of VB - I suspect VB4 - and requires you to do fun things like manually registering OCX files, installing services by hand, and editing both INI files and the Registry. It uses DEX for the rules calculation stuff... a product that was initially developed in the early-90s, I believe. The data is stored in an SQL database, which is fine other than the quaint way the middleware component wants to write stored procedures to the master db on the server, not just its own db. Writing things to the master db is really not that desirable when a server is hosting literally dozens of databases. What happens if some other db decides to call its stored procs the same name and store those in master as well? Just ridiculous.
We got it up and running after quite a bit of angst with replicating the old server's installation of the middleware, and restoring a copy of the old database from backup to the new SQL server, albeit with a different name. After running a few simple tests from a client, we then tried to run a crucial import procedure that picks up personnel data from SAP. The middleware component connects to a drive where SAP has dropped its data (by means of a quaint batch file), and also to its own database, and then runs a compiled executable (nothing so transparent as a script to process the data, because then we might see what it's doing) and some of the stored database procedures to jam the SAP stuff into the database. Now, getting the thing connected to its own database on a remote server was fun anyway - after we sorted out the master db malarkey - because it requires you to configure an ODBC connection to the new database on the middleware server AND run the middleware client once and configure the new connection information again, which it drops into the dreaded INI file.
Our import kept failing at the point just before it updated the data into the database. I got the ODBC tool logging the SQL output passing through it, and found that it referenced the OLD database connection information about 10,000 lines through the import job... just before the failure. Now, remember that it had read the ODBC connection information and the INI file to connect to its database to do the stored procedures and various queries for processing the data -- when it came time to jam the information back in, guess where it was reading the connection information from? No, not the ODBC. No, not the INI file. It was reading it from a field inside the database it was already connected to.
GAHHHHHHHHHHHH!
That import connection info field happened to be configurable from inside the client (not the middleware) GUI, so we didn't have to futz around inside the database, but why why why it's even an option is totally beyond me. The clients and the middleware are only ever connected to the one database, so where on earth else would you be importing the data to? And since you can't run the import without being connected to its own database, and you can only be connected to one database at a time...? (Exporting it in a configurable way makes sense.)
And this is just trying to replicate our existing install. I am soooo waiting for the actual upgrade, which requires that we install the .NET framework on the middleware server... V2 and V3 (I mean, WTF?), and then run no less than 6 conversion scripts, two for the database and 4 for the middleware and clients. Again, they can't provide us with just a new fresh installer and perhaps a db upgrade script.
Still, we're getting there. Also on the exciting things actually working front, I have a version of Trac and Subversion installed on a Linux server to manage source control in our organisation, and it's all working great, complete with Active Directory authentication and reasonably granular directory permissions. I just now have to break the news to the SOE team that no, they cannot have a separate Trac project for each and every application they maintain. Of which they have scores. They can consider their applications as components of a SOE version. So there. Because I'm not going to sit there and twiddle with zillions of little projects constantly. The next thing is to see if we can mirror the Subversion repositories to a remote server for DR purposes (and have it update itself constantly). Eeee!
