11-25-2013 05:09 AM
Thank you for your reply. Unfortunately, this is our production environment. Everything I have heard and researched indicated that I should be able to deploy the web portal in conjunction with our LAN environment with no issues.
Did Swiftpage relay the information about this defect and I just missed it? This seems like a pretty huge defect.
I looked in the systeminfo table and there is an APPID populated in both my remote database and in the host. What is this used for? Is there any way for me to change the APPID to make everything work?
I do appreciate your response!
11-25-2013 05:14 AM
11-25-2013 05:15 AM - edited 11-25-2013 05:24 AM
I just discovered something that I missed from previous posts... the "sitecode" in the SYSTEMINFO table on the remote database had been set to the HOST SITECODE, not the REMOTE'S SITECODE. Once I changed this, I was able to log into my remote! Details: I updated the systeminfo table to the following in the REMOTE DATABASE:
** DBType = 2 (used to be 1)
** SiteCode = OBKD (used to be 6UJ9)
** PingServer = remote user's computer (was set to the HOST server, 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 grateful for all the support out here!!!
11-25-2013 05:24 AM
Is that what is currently in the systeminfo table on the remote?
If that is the case then the remots sitecode has been updated to 6UJ9 and needs to be changed back to what the remotes sitecode was, you cshould be able to determine the users sitecode from within Admin, add the sitecode column to the users grid, you would then need to update the sitecode on the remote to that, this should then be fine.
You will need to identify the sitecode for each specific remote and update the sitecode for ALL remotes.
11-25-2013 05:25 AM
Thank you!! I think I discovered this at the same time you responded to my post. If I make these changes in all remotes (somehow send out a sql update command that they can run locally?), do you suppose everything will be back to normal?
11-25-2013 07:05 AM
APPID is part of "Integration". Specifically it is a foreign key that points to an entry (PK) in the APPID table.
Unless you are (currently) running Sage X3 accounting - it means nothing. Sincs Saleslogix is no longer owned by Sage.. I'd SWAG going forward the "integration" functionality (based on "SData Contracts") will certainly expand to non-Sage integrations.
11-25-2013 08:43 AM
FYI - This is not an issue for 8.1:
.. From a GOOD source ;-)
The logic has been removed from the web client and moved into a conversion utility.
The conversion only updates the AppId directly via the provider so not other information from the SystemInfo table will sync to the remote.
.. and said they will look into a fix for previous versions (that may have the issue).
11-26-2013 04:58 AM
Just a note for everyone... we do not use "Integration" and still the SYSTEMINFO table was updated in all of our remote user's databases. Bascially, the following fields were set to the HOST database settings, which broke all remotes. We are trying to figure out a way to send an "automatic" fix for this. If we can't get this fix to automate, that means I need to get in touch with 202 remote users all over the world, and manually fix their SYSTEMINFO table. NOT a happy camper right now... guess I know how I will be spending my Thanksgiving holiday....
What the SyncServer sent out and updated:
SYSTEMINFO.DBTYPE - changed the value to 1
SYSTEMINFO.SITECODE - changed to the host server value
SYSTEMINFO.PINGSERVER - changed to the host server value
I need to (most likely) manually update to the following:
SYSTEMINFO.DBYTPE = 2
SYSTEMINFO.SITECODE - change back to the remote user's sitecode
SYSTEMINFO.PINGSERVER - change back to the user's servername (computername)