I have a client who recently upgraded from SL 6.5 to SL 2011 that has 2 different system databases each with its own application database and they need to switch back and forth between the system databases. They are using SQL authentication. They are looking for the most efficient way to switch between system databases. The way the yare doing it now take several more steps then version 6.5 did. They cannot use the switch companies since the companies are under separate system databases. they have to close the current company, click on find database, specify the SQL Server instance, select the other system database, enter their credentials, get the warning that the company ID does not align with the system database and, finally, the company field shows so that they can select the correct company ID. This is a bit messy under SL 2011 since it does not expose the company ID field on the log on screen like version 6.5 did.
Is there a better way to handle this type of situation? Version 6.5 works better for sure for this type of scenario.
I'm responding because I would like to know if someone has come up with a way as well. I have a client doing the same thing.
Follow me: @butch_adams
Good morning !
As I know.... You need to configure mutli-company
So you need one system db and two app db
Thanks for the response but multi-company is not the solution to this. Its purpose is to manage inter-company activities and such. While you are correct that, if both application databases were under the same system database, you can use the Switch Company feature to move between databases. However, this client has separate system databases for a variety of reasons. the issue is that the newer versions of SL (7.0 and 2011) made it easier to move between application database (under the same system database), that very ease of use change made it cumbersome to switch between system databases because the added cache logic to away the old log in screen process (well, not actually took it away but attempted to bypass part of it when switching databases). So, now, the user has to go through a lot of extra steps to switch system databases.
The purpose of this post was to see if anyone had found a way around this situation. Primarily, if someone had found a way to purge the cache that remembers where you last logged into. I am not looking for a way to use the Switch Company (though that would be ideal) but, rather, a way to close SL and fire it back up again such that it then presents you the option to find the system database (which it still does) and then, after specifying the system database, presents the company field so they can enter the correct company id to go with the other system database.
Yes, You are right
Why not you just only merge your 2 app db into one system bd? Of course you'll need to recreate the security settings of he merged app db and also you'll share the customizations, rptcontrol, pvrecs, etc
If you don't want to share the customizations you can assign it to a group with only members of company2
The user's profile contains the user's Solomon.ini file.
C:\Users\(username)\AppData\Roaming\Microsoft Dynamics SL\Solomon.ini
You can write a small program for your users that edits this file for them on the fly.
They would, of course, need to close Parent.exe first (to unlock the ini file for editing).
Then push a button to switch/flip-flop the SYSTEM and App DB the user is defaulted too.
When you reopen SL, it should autoconnect to whatever you placed as Sys and App in the ini file.
|̲̲̲͡͡͡ ̲▫̲͡ ̲̲̲͡͡π̲̲͡͡ ̲̲͡▫̲̲͡͡ ̲|̡̡̡ ̡ ̴̡ı̴̡̡ ̡͌l̡ ̴̡ı̴̴̡ ̡l̡*̡̡ ̴̡ı̴̴̡ ̡̡͡|̲̲̲͡͡͡ ̲▫̲͡ ̲̲̲͡͡π̲̲͡͡ ̲̲͡▫̲̲͡͡ |
We had a similar scenario in DSL7.0. We use terminal servers and a seamless app. So we created two network logins. This allowed the users to have different Solomon.ini files for each network user that would have different databases associated with each one. This also allowed them to be logged into each DB at the same time so they could compare information between the two.
Thanks for the suggestion. I will consider this but my initial thought is that logging in twice and having to bounce between logins is as much work as going through the extra steps to switch system databases.
Obviously, when Microsoft reworked the login feature in 7.0 to make it easier to switch between two application databases under the same system database and to re-connect to the same database you were last in, they did not think about how that affected situations with more than one system database.