QPR Proces, Language models

8 posts 0 new
Log in or register to post comments.

QPR Proces, Language models

Hi,do some one have experience with automaticly changing language models?In our company we have two domain. One is @skanska.cz - Czech Republic, second is @skanska.sk - SlovakiaI do have language model in version for Czech and Slovakia.It is possible to define users anywhere with the account @skasnka.cz automatically opened in language model CZ and @skasnka.sk will automatically open a language model SK.ThanksAdam

Not sure if it's automatically possible but at least the users can define the language for themselves in the Portal settings. This setting is then remembered the next time the user goes to the Portal.

Yes, I know that Portal remember settings. It must therefore be recorded somewhere, what language model user chose to view, otherwise it would not work properly.

When it written somewhere that it could be set anywhere. I want to make it more user-friendly. I would accept that solution i will modificate myself for new users.

It occurred to me that I could change in SQL . Can you please advise what SQL table that I look for? thank you

The Modeling Language is located in the QPRNUM_APP_DATA table, UAD_KEY = 'MODLAN'
Modeling language is the id of the language from QPRUM_ASSOCIATION TABLE.

Backup the DB before making any changes.

The drawback is that the SQL command needs to be run every time there are new users in the system. And the system needs to be shut down during the operation.

Olli, can You please elaborate a little more as to why it's necessary to shut down in order to perform a simple UPDATE?

It's because of the way QPR application servers are functioning: In the startup the information is read from the database into server processes' memory. If you make an SQL update while the QPR server processes are running, the processes are not aware that information in the database has been updated. This leads to a confict as the information in memory and database are not consistent. This may result in crashing of QPR servers or even database corruption.

In addition to better performance, there is another advantage of this behaviour; QPR system may still work even if the database connection is lost.