Remoting odbc data source

Author: (rogerw)

Hi! This is probably an easy/strange question for those using urouter/userver every day. In Uniface, having a typical client installation and all database accesses directly in the form, using retrieve and store going through the read and write trigger of the form. Furthermore a local client asn-file, using a  local odbc data source "MyDataSource", installed on every client pc to connect directly to the database. CLIENT.ASN $MSS    MSS:MyDataSource:mydatabase|myuser|mypassword $DEF    $MSS I've understood that you should be able to move the client odbc data sources to a server without doing any changes to the forms (not having a typical three-tier Uniface application), ie. having the odbc data source on just one server machine. Does anyone have experience from this kind of installation, slow or fast? What do you need on the server, just urouter that redirects to the database or "urouter + userver" or how is it achieved in a simple way? Sorry, Im not an Uniface server expert! Any comments appreciated. Regards RogerW.


  1. Urouter.asn on myserver [SETTINGS] $default_net = TCP:+13002||| CLIENT.ASN $MSS     TCP:myserver+13002||| + MSS:MyDataSource:mydatabase|myuser|mypassword $DEF    $MSS Should this work, although I can't get it working? Regards RogerW. 

    Author: rogerw (
  2. rogerw said Urouter.asn on myserver [SETTINGS] $default_net = TCP:+13002||| CLIENT.ASN $MSS     TCP:myserver+13002||| + MSS:MyDataSource:mydatabase|myuser|mypassword $DEF    $MSS Should this work, although I can't get it working? Regards RogerW. 

    Hello RogerW, I'm missing a few things: 1. The network path (TCP:) needs UserName and Password plus an UST (Uniface Server Type); if the UST is omitted then the UST called DEFAULT should be used 2. A [SERVERS] setting section and at least one (DEFAULT) UST definition 3. A ASN file for the UServer with a [DRIVER_SETTINGS] setting section where the MSS connector version is specified Urouter.asn on myserver (Uniface is installed in C:\Program Files\Uniface\Uniface 9.6): [SETTINGS] $default_net = TCP:+13002||| [SERVERS] DEFAULT = userver.exe /adm="C:\Program Files\Uniface\Uniface 9.6\uniface\adm" /maxidle=3mMSS = userver.exe /adm="C:\Program Files\Uniface\Uniface 9.6\uniface\adm" /dir="C:\Users\Userver\Documents\Uniface 9.6" /asn=mss.asn MSS.ASN (Userver ASN): [DRIVER_SETTINGS] MSS = U4.0 ;usys$mss_params=<required settings> CLIENT.ASN: $MSS     TCP:myserver+13002|mynetworkuser|mynetworkpassword|MSS + MSS:MyDataSource:mydatabase|myuser|mypassword $DEF    $MSS I'm currently not sure if I've missed something. It, however, might be a good idea to add $putmess_logfile to the different Uniface processes (and, if necessary, for debugging purposes $ioprint=255) in order to catch any error messages. Hope this helps. Regards, Daniel

    Author: diseli (
  3. Thanks Daniel, I'll soon test it more. At least you mean that it should be possible, although the application isn't a typical Uniface three-tier application. It's not that obvious that this scenario should work..... Perhaps something that should be noted and developed further to get a webalike installation. On the other hand Uniface is investing on web-programs and html5, which of course might be the right way, presuming that it gets easy, efficient, competitive etc. And yes, I know about JTi.  Regards RogerW.

    Author: rogerw (
  4. Hi Roger, This looks like the old PolyServer scenario...  I'm not sure why you would specifiy the username/password for the MSS connection in the client asn as this would mean everybody can see / change the password (esp if the asn file is on a fileserver). So, I'd use the $MSS settings sans db specifics, $DEF = $MSS and move the db specifics to the server asn. And - ensure you have USRVMSS key in your SERVER license.xml file - without it, it ain't gonna work.... Cheers,Knut

    Author: Knut (
  5. Thanks Knut, We do have USRVMSS on our development license, so I'll probably have to test by using a development pc as server (perhaps my own). But it was nice to know about that. You are probably right about the db specifics. However we do have a nice encryption of the username and password for the client, but if I get it working I will for sure try to move it to the server. Regards RogerW.

    Author: rogerw (