Does the remote database need to be replaced after SLX754 upgrade?

[CPKHEM]

We're preparing for the upgrade from SLX 752 to 754. Here's a question I have - do we need to replace remote users databases after the upgrade? We have about 300 remote users and it's not realistic to have all their databases replaced all at once. Has anyone here done the upgrade without replacing remote users' databases?

Also, we're running into an issue after the security patch was applied on the test server for the web portal. After remote client upgrades and syncs, remote client is getting this error message:

"The provider on Server VMDS0000A (local machine name) is no longer in use. Please change your connection to the provider on server VMDS30AFF (test server name)"

Anyone experienced the above? Please share your insight. Thank you in advance.

Christine

[MikeSpragg]

No, there is no need for a recut at all. Should all sync through. If this is a remote user - the host server shouldn't have anything to do with this (check systeminfo - what's the dbtype?) as the client connects to the local server (which is being reported as 30AFF below) - not the host.

[CPKHEM]

Mike, I appreciate your quick reply.

That's what I thought, remote databases would not need to be recut. We have been syncing thru the changes and a test remote was working until we applied the security patch for the web portal, we synced the server and remote, then all of a sudden the test remote now gets the provider error message and is not able to log in anymore.

I think somehow the security patch updated the systeminfo table on the test server and changed the PingServer value in SystemInfo table to be the machine name of the test server. Then the changes synced out to the test remote and in the test remote SystemInfo table, the PingServer value is now also  the machine name of the test server. We're not able to manually update the PingServer value on the test remote to be the local machine name. Got error message "LoggingServer does not have access to the specified logging path. Please contact your system administrator”

Dbtype on test remote shows 1. I'm not sure what it is on the test server. Will need to check and get back to you. Thanks again.

[susanrn]

We are currently running LAN v8 of SalesLogix with about 250 remote users.

I deployed SLX Web in production Friday evening (we want to start moving in this direction) and something went out in the sync that broke all my remotes.  I am having similar problems as you described.  The Remote Clients were working fine, then, after the sync, they got the following error when trying to log into the remote client or the sync:

"The provider on server (REMOTE'S COMPUTER NAME) is no longer in use.  Please change your connection to the provider on server (PRODUCTION HOST SERVER)"

I got onto a remote users' computer and went into the connection manager, and did a "test"; everything tested out ok, in the data link manager, everything test out OK, then, when I tried to log in again, I got the error "LoggingServer does not have access to the specified logging path.  Please contact your system administrator."

I'm stuck at this point and have no idea how to get my remote users functioning again.  

I also looked in the "systeminfo" table on the remote database and the "dbtype = 1".  Is this a clue to something?  Did you ever find out what the issue was in your system?  

Thanks for any help that anyone can give... I'm desperate.  thanks!!

[MikeSpragg]

Somehow - your remotes got broken. The dbtype should 2 (remote user) - not 1 (main office) - which explains why they can't get to the logging path (which is on the main server). If you change this, the remotes should work again.

[craigf]

Hi,

I encountered this issue at a clients, it is apparently something to do with logging into web the first time and a SQL update which should be executed against the host syncs out, however this obviously does not happen on ALL sites, as I have upgraded others and not seen this issue.

As Mike advises changing the DBTYPE back to 2 will set the DB as a remote again, however certainly in our case, the sitecode of the remote was also changed to that of the host DB and the pingserver also changed to that of the host DB.

So you will need to update the DBTYPE = 2 and sitecode to what it was previously, the remotes will currently have the hosts sitecode, 6UJ9 (for example) the pingserver will also need to be changed, however this can be updated by just applying the connection manager entry.

Hope this helps.

Regards

Craig Frayne

QGate | We make CRM work

[susanrn]

Thank you so much for your quick reply!  I changed the dbtype  = 2 for one of my remote databases and fixed the pingserver by going into the connection manager. 

I then tried to log into SLX and got a message "<6UJ9> Unable to find a valid sync server for your site code." 

I then looked in the siteoptions table in the remote database for that site code (saw a post somewhere) and the "lastrnfile", "hostserver" & "data" fields are null.  Is that where the sync server is stored?   This entry does not look like it was updated recently (the modify date is back in 2001) so I'm suspecting that I'm looking in the wrong spot.

Where should I look to see how to resolve error?  Again, I so appreciate your help!!!

[susanrn]

P.S.  When looking in SalesLogix admin at this remore user, the sync server and all sync options look perfectly normal.  We have 250 remote users, so while I believe cutting a new database would resolve the issue, I would like to see if I have some other options first.  Thanks again!

[susanrn]

I deleted my original comment - i had typed bad data - I need to revise to the following 

When I re-read your post, Craig, I noticed you said that the "sitecode of the remote was also changed to that of the host DB".  Maybe that is the piece I'm missing... I just looked again in my systeminfo table and my sitecode was set to 6UJ9 which is the site code of the HOST DATABASE, not the remote.  I updated the systeminfo talbe to the following:

SystemInfo = Primary

DBType = 2 (used to be 1)

PrimaryServer = OKTT

Data (hex)

DBVersion = 8.0

SiteCode = OBKD (used to be 6UJ9)

PingPort = 51101

PingServer = remote user's computer (was HOST, but was corrected with going into connection manager)

NOW I CAN GET INTO MY REMOTE DATABASE!!   However, if anyone can give me some more feedback on this, I would be forever grateful.  Can I assume, if I make a SQL Update to the SYSTEMINFO table on all my remotes to:

1. Change the DBType = 2

2. Change the SiteCode to the remote site code

3.  Change the PingServer to the remote's computername (slx server)

that everything will be good to go?

Very greatful for all the support out here!!!

[CPKHEM]

Hello, I'm very sorry to hear that you ran into this issue as well. Just hope it's not in your production environment and my response is not too late.

We found out this is actually a defect with the service that generates the App ID in the system info table. This issue happens on some systems when making the first login to the web portal after the upgrade. The defect is there's no App ID in the system info table after the web portal upgrade, as soon as you log into the web portal, a new App ID is generated in the system table and it's syncaware, then this row with the new app id gets synced out to all your remotes and remotes can't sync anymore.

Luckily we encountered this in our test environment. But it did delay our upgrade schedule. Our developer had to roll back the test environment and start the test upgrade from scratch. We worked with Swiftpage support and they created a script for us to populate system info table with an app id before we logged into web portal after the web portal upgrade.

I hope this will be helpful. Swiftpage support should be aware of this already. Hope you will get it resoved soon. Good luck.