Looking for users of ADP Enterprise eTIME. 1

[MasterRacker]

Warning: this is not strictly a SQL server question - just a product that uses SQL server.

The situation: we are getting vendor runaround regarding moving a database. EeTIME is a large scale time & attendance package. There are a couple of server based processing pieces and a Web server that talk with a SQL 2000 backend. We are bringing some new servers online and moving our databases to the new servers. I would call this sort of thing "normal" operating procedure for any reasonably large company with multiple DBs.

Our proposed migration method was to backup the DB, restore it to the new server, run some scripts that resync the SQL IDs SIDS to the new server, change the system DSN on the app servers to point to the new DB and away you go. (Of course, this didn't work or I wouldn't be posting. ;-) ) After the failure, their support escalated to their "Shared Services" group. It came back that ADP does not consider DB migrations part of normal support. Their assistance with this task is fee based. Further, they claim that they have very few customers that do this.

ADP is the #2 payroll processor in the country and has some very large clients, many of which, I would guess, are also using their EeTIME product. There's no way these companies aren't moving their DBs around or that they're all paying the vendor to do it for them. Even ignoring normal migration issues, from the disaster recovery point of view, any large company has to be able to restore a database to any available server to maintain business continuity.

I did get some free info out the the Shared Services group, but that basically referenced the installation guide and listed the same steps we performed. I guess what I'm doing here is trolling for any ADP EeTIME users out there who are familiar with the details of moving the database. Anyone out there?

_____
Jeff
[small][purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day
"The software I buy sucks, The software I write sucks. It's time to give up and have a beer..." - Me[/small]

 

[mrdenny]

I've got eTime. We did a migration about 8 months ago to another server. On the eTime servers find the WFCSite.properties file. You are looking for the site.database.adpeet.url line. That's got the actual database and server info.

I'm checking with my SE to see if there was anything else to do.

Who ever you talked to at ADP sucked. We got all sorts of help from them for free. Moving the NexTrak product was another story. That we had to pay for, but they helped us out with the eTime system for free.

I don't see anything specific in our Change Control system. I'll get back to you when he gets back to me.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

 

[mrdenny]

And this is why my SEs rock. He said that we had a couple of config files on each eTime server. Do a search of the servers hard drive using the "for text inside document files" for the old server name.

Also anyone using the fat client will need to have the DNS updated.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

 

[MasterRacker]

MrDenny,

Excellent info. No one has mentioned those files at all. (We've never really dug into this app because it generally "just runs".

So to summarize:

1. Move the DB and resync the SIDs for the SQL IDs.
2. Search through the config files on the app server for the old server name and update where found.
3. Update the DSN on the app server, fat clients and DCM.
4. Fire it up and celebrate success.



_____
Jeff
[small][purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day
"The software I buy sucks, The software I write sucks. It's time to give up and have a beer..." - Me[/small]

 

[mrdenny]

Yeah, that should be about it. If you have there NexTrak product that also needs it's own changes. Do you have it as well?

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

 

[MasterRacker]

Nope. Just eTIME. One DCM, One Web server also running the BGP. 4 workstation with fat clients.

I was told we'll also have to investigate our AConnect scripts in case they were improperly written with UNC paths.

_____
Jeff
[small][purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day
"The software I buy sucks, The software I write sucks. It's time to give up and have a beer..." - Me[/small]

 

[mrdenny]

You are lucky. The NexTrak was a pain.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

 

[MasterRacker]

mrdenny,

So, last Friday we were able to get this move done successfully. I've got one issue left however. I have 3 workstations that do imports/exports through AConnect. 1 works and the other 2 don't.

On all 3 I've changed the ODBC DSN to point to the new server. I've since searched the registry and done a text search for references to the old server. I found one registry reference to the old server, however that was incorrect even on the machine that works. I can't find any differences between the machines. I know the problem is machine related because on one of the non-working ones, I've logged in as more than one person and gotten the same problem.

Our DBA has verified that the machines are trying to authenticate to the old server, but as I've said I can't find any reference to the server other than the ODBC setting.

Also, the actual import/export scripts are on a network share, so they are all running the same script. Did you run into any issues like this? I'm at a brick wall in the fog at the moment.

_____
Jeff
[small][purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day
"The software I buy sucks, The software I write sucks. It's time to give up and have a beer..." - Me[/small]

 

[mrdenny]

I'll check with my SE and get back to you.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

 

[mrdenny]

Here is what my SE said.

I would look at the configuration file(s) in the application install directory to see if there is any reference to the old SQL server (or database).
A text string search with the old DB name for all the files in that folder might be faster than trying to figure out which file is the right one.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com

 

[MasterRacker]

Found it! Turns out that the AConnect client had been installed differently on 2 of the machines. There are also environment variables (ick) involved. Even changing the environment didn't fix it though. I had to uninstall and reinstall the client.

What get's really interesting, scary and magical is that the install never asks for a DB location. Apparently, in a mess that carried forward from a previous version (installed before my time here), our license files are split into differerent locations and mixed up. 2 of the client pointed to one set and the working one pointed elsewhere. Somehow, through the license files the client is able to find the database (not the actual import scripts ?!?).

Another magical aspect of this program is that the installation somehow decides on it's own if it's going onto your C: or D: drives (the setup program never asks.)

Bottom line, it all works and our DR procedures are now documented (if not fully understood.)

Why do any of us work in this field anyway?



_____
Jeff
[small][purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day
"The software I buy sucks, The software I write sucks. It's time to give up and have a beer..." - Me[/small]

 

[mrdenny]

Awsome. Glad that it's working.

Denny
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / Microsoft Windows SharePoint Services 3.0: Configuration / Microsoft Office SharePoint Server 2007: Configuration)
MCITP Database Administrator (SQL 2005) / Database Developer (SQL 2005)

--Anything is possible. All it takes is a little research. (Me)

http://www.mrdenny.com