pencrypted

Today was to be the day that months of work would finally finish. This was the day that the time collection system was to be migrated to the new server and upgraded to use an SQL database.

The rep from TimeTach, we shall call him Jack, was to show up at 10:00am from Mississauga. Amazingly he was on time and we set right to work. First task was to copy the database files and run a test conversion to ensure that nothing has changed since the last test. They (TimeTach) had tested this before in their office and had found numerous issues,but had worked through them. Naturally I assumed we would be converting the database using the same procedure they had used in the tests. I was wrong. We went the opposite direction. Instead of converting the entire database and correcting the errors later, we only converted the critical tables. This path turned out to be full of issues and it was finally decided to recopy the database to the new server and do a conversion of the entire database, the way they had tested it.

The test conversion worked perfectly. At this point we took a break for lunch as it was approximatly 12:00pm. After lunch we stopped all tasks on both the old Timekeeper server, and the tasks running in Navision. This essentially stopped the databases from updating anymore. Any data from this point till the upgrade was complete would be stored either on the clocks, or in Navision. I should take a break here and explain the data flow both in the old system, and what it should be in the new system.

Timeclocks: Are what employees use to clock in and out of jobs. They wand to their employee badge, then a task code, then a job code.

Timekeeper: Software that is used for payroll and tracking employees on jobs.

Navision: ERP system to keep track of all data related to orders, jobs, hours, employees…pretty much everything aside from actual cad data.

Old System: The old system consists of two servers. One server (CLM-VM) is running both the Timekeeper software, and the Connection Manager software. The other server (Navision) is running Navision. The data from the timeclocks is pulled to the CLM-VM server using Connection Manager, Connection Manager then updates the info to Timekeeper which then exports a data file which Navision then reads in over the network. This then works in reverse to send new jobs to the timeclocks. Timekeeper uses a Foxpro database in this scenario, which is the cause of most problems as it is too slow to read through all the existing jobs. Obviously there are more details, but that is the basic gist of the process.

New System: The new system should consist of one server. All of the above mentioned programs are on one server, but the process is similar. In this scenario, Timekeeper has been updated to a SQL database. Much faster.

New Ghetto System: This is the scenario we were aiming to accomplish today. Timekeeper is updated to SQL and moved to the Navision server. Connection Manager is not as it is too old and no one knows how to move it yet. So all the data to be sent to/from the clocks would still go across the network, but there would be no huge database queries over the network.

From here on out it should have been the simple task of converting the database to SQL and changing a few settings in Navision and Connection Manager to point to the new directories. The conversion went well and we tested an export from Navision to TimeKeeper with great results. At this point we installed TimeKeeper clients onto the human resources dept workstations.

Filled with happiness we started to set Connection Manager to point to the new TimeKeeper server. This is when Jack discovered a critical issue that they had not anticipated, or prepared for. The Connection Manager software was not in fact reading in a file exported from Timekeeper to get the data to send to the clocks. Connection Manager was in fact interfacing directly to the TimeKeeper database to get its data.

I thought this was great as it seemed much more efficient than running another export. Jack did not, as there was no way to get Connection Manager to interface with the database over the network. There was also no way to install Connection Manager onto the new server as no one at TimeTach knew/knows how to. Seeing as it was 6:00pm and we had stopped all new jobs from going to the clocks for six hours, we had no choice but to undo all the work that was done and revert back to the old system. So all in, a waste of an entire day and we made no progress aside from finding out ahuge flaw.

I am shocked that this was not discovered until now, as the company that was doing this upgrade for us, is the exact same company that initially installed the system six years ago. The only thing we gained out of this little adventure today is the knowledge that TimeKeeper SQL at least works with Navision. Although I must say that I am happy to start seeing results from TimeTach, and Jack really did try to work around most of the issues. Unfortunately, you can’t be an expert on everything.

Yay for wasted time.

Note: All server names are not real.

This is a work related note.

Recently we decided, nay, were forced into upgrading our Navision system from version 3.6 to 4.0 SP3. This was so that we could install the client onto any new workstations we purchased that came with Vista, as Navision 4 works in vista. I should specify that we didn’t upgrade the database components, only the server and client executable. Not much work.

I purchased a new server to run the Navision database on, this server would also be running the timekeeper database as well, so I bought something fairly beefy: Dual Xeon X5405 processors (2.0ghz Quad core), 4GB 667mhz RAM, 3x 146gb 2.5″ 10k rpm SCSI drives in raid 5, dual gigabit NICs.  I installed Navision 4.0 server onto the server and it sat for a few days as TimeTech installed timekeeper onto the server in preparation for testing. We needed to test the interaction between timekeeper and Navision, as they send data back and forth between their databases to send time/job info to the wanding stations on the plant floor.

The initial tests looked good, so I set up a few workstations up with Navision 4. client installed in parallel. This was to ensure that securities and such were not broken when we converted the Navision database to 4.0. There were a few initial security issues as Navision 4 treats some thing differently than Navision 3.6, but these were resolved quickly and written down for later reference. Since everything was going so smoothly, I decided on an upgrade date of Wed, Jan 14, for Navision. This was only going to be Navision that would be upgraded on that day, Timekeeper could wait till the next week.

Wednesday rolls around and I am at work with Scott at 5:30am, ready to start the update process at 6:00am. We got an early start at 5:50am as all the jobs on the database had been completed. I shut down the services and start to copy the database files to the new server. This will only take 20mins or so as it is only 18GB. In the meantime we start running the upgrade on the client computers using the Microsoft supplied discs for Navision 4.0 (sorry, we’re supposed to call it “Microsoft Business ’solutions’ - Navision” ). The installer is able to do an upgrade using the existing Navision 3.6 install.

The upgrade is very quick for each client, a simple install and a reboot. We are flying along and already had 13 or so workstations done when I noticed that they were all starting to give SQL errors on reboot. Upon further examination, our disk management software had failed, along with Smarteam (our second most used program in the building), system restore, Internet Explorer, and Windows Search. They all would crash immediately.

This confused me as I had installed the client on no less than six computers just a week prior and had seen no issues. The only thing I could think of that had changed, was the uninstall of Navision 3.6 when it was upgraded to 4.0. To see if this was the issue, I decided to uninstall Navision 3.6 from a workstation that had had Navision 4.0 installed in parallel the week prior. As soon as I uninstalled Navision 3.6 the system exhibited the same symptoms as all the workstations that had been updated. To top it all off, we couldn’t uninstall any programs, or reinstall anything, that errored out as well. This was not good, seeing as it was almost 8:00am.

For a laugh, Scott and I decided to try a repair using a windows install disc. After 37 minutes of teeth biting as the repair ran, I was happy to see that the issue appeared to be resolved. We quickly started repairs on the other 12 workstations and decided on what to do with the failed upgrade. In the end it was decided to go ahead and install the Navision 4.0 client on all the workstations in parallel to Navision 3.6, this way at least we could use the new database. Not ideal, but the best we could do given the situation.

What kind of crap software nukes an OS when it is uninstalled? Especially when it is the same manufacturer!? These were completely up to date systems, with the exception of SP3. My only thought is that Navision 3.6 is so old, that the uninstall removes a component, that 8 years ago was not vital to windows running, but now is. Thus windows refused to work with the missing components.

At 11:30am we finally switched over to the new database, only 3.5 hours late, and with 3.5 years taken off my life. Tomorrow, we tackle the Timekeeper upgrade.

F*ck you Microsoft.

Well, catching up on all the work I missed while sick. Most importantly are some drafts of a brochure. I used Photoshop to do some mock ups of some designs that I was asked to produce, as I can work a lot faster in there than in InDesign.

After I had a few mockups I wanted to ensure that I could put them into place in InDesign. One of the effects was a chiseled steel look on some text,with a brushed aluminium background. I know, not my favourite, but none the less. Seeing how InDesign won’t be able to render it, I knew I had to put the background in as a *.tif. The text however, should be made in InDesign natively, as to aid in certain changes that will be made to it’s wording further on down the line.

Well, I set up the background image exactly as it should be, set up the text, and the went to add the text effects. Bezel and emboss worked fine, however, as soon as I added the color burn to the object, it failed miserably. Seems Indesign doesn’t like color burn, as all other transparency effects worked appropriately with the bezel. Alas, I am stuck until I figure out another way to get the effect. I don’t want to throw the text in as an image, as scaling will be miserable.

The settings below are the exact same in InDesign as in Photoshop.