Javier,
Whether the engine DLL is embedded within or located in the same folder as the
compiled executable, the speed for accessing the database is
relatively the same.
Pros for embedding the DLL within the compiled executable have always included
portability and security for the R:BASE application. However, with
newer operating
system releases and new security protocols, the embedded DLL has become a less
favorable environment for R:BASE applications. Try using the compiled
application
with and without the embedded DLL to see which setup is more ideal in
your network.
There will be no speed decrease in any R:BASE module when upgrading to R:BASE X
for Windows. To address possible sources for your issue, review all lookups
(for variables, lookup controls, etc.), in addition to tables/views which data
are retrieved for the lookups.
The following will assist in your use of R:Compiler for R:BASE when
using Database
Resources like :
When running a compiled executable the resources (forms, reports,
labels) can reside
in the executable AND the actual database files, however the resource
which resides
in the executable will be recognized first. If a resource has been
removed from the
database, and needs modified, the item can be copied from the
R:Compiler project to
the Database Explorer. If the form is changed, the form in the
R:Compiler project
must also be updated, and the project must be recompiled. If there is
active database
development taking place for a form or report, the resource should be
left out of the
R:Compiler project until all concerns are addressed.
The RAMS-XE is the correct naming convention with the R:BASE version
being R:BASE X
Enterprise RBGXE, not RBGEX. Your concern over the name is understood. <gr>
Very Best R:egards,
Razzak
At 02:14 AM 12/15/2015, Javier Valencia wrote:
R:azzak,
I was under the impression that embedding the RBENGINEXE.DLL speeded up the
database. Do I understand correctly that not compiling the RBENGINEXE.DLL
into the application and just having the file in the same server directory
is faster?
This is something I need to check pronto; I just upgraded the most recent
version on my client system and a lot of forms are loading extremely slow,
one takes a minute to load where in 9.5 took only a few seconds. Sparing the
files from the anti-virus helped some but it is still very slow; I need to
trace and see if the delay happens in the form that calls the target form in
question or in the target form itself.
Also, I am not clear on how compiling a form or form into the application
works. We upgrade forms in real time and just load them into the live system
and when the user re-accesses form the new version is displayed; this is
extremely helpful.
Now, If I compile a form in the application, does it remove it from the
database or does the form exist in both the database and compiled
application? What happens if I load newer version of the form into the
database? Does the database use the most recent version of the form or
always the one that is compiled? If this is the case, the only way to update
a form would be reloading it and recompiling the application, Is this
correct?
BTW, the enhanced grids seem to work faster in R:Base EX.
On a lighter note, our application name is Roadway and Asset Management
System or RAMS for short and we have in the past used the same version
number as the R:Base version; the previous versions were RAMS 9.1, RAMS 9.5
and so on. The current version is labeled R:Base EX and our application name
would have been RAMS-EX...for obvious reason I decided to call it RAMS-XE
instead... :)
Javier,
Javier Valencia, PE
O: 913-829-0888
H: 913-397-9605
C: 913-915-3137
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of A. Razzak
Memon
Sent: Monday, December 14, 2015 6:05 PM
To: [email protected]
Subject: [RBASE-L] - Re: Multi user and Config Name User
At 06:24 PM 12/14/2015, Tom Frederick wrote:
>We have several questions related to our compiled database (RBaseX
>Enterprise).
>RbaseX.dat is the file used to build ElmCityDatabase.exe. The Rbase
>engine is embedded along with one theme (Longhorn) used for messages.
>RBengine.cfg is on
>the server where the exe is located. The current config file has an
>item called Name:USER 20151129130838. How is this user ID used? If four
>users get on our system through the exe on the server, they would all
>use that config file which has that USER ID. Does this user ID apply
>the same to all of the users so that user ID is used four times? Or are
>each user tracked through other means like the User Privileges section?
>I have not used the Privileges at all, which can explain some problems
>we have had with unannounced shutdowns. The database is simply great in
>single user. In multi it works well, but I keep finding little tweaks I
>missed. This is just the next item that has come up. Thanks.
Tom,
Have you looked at the recent R:BASE X Enterprise Compiled applications made
available lately at http://www.razzak.com/sampleapplications/
Installing and deploying those applications on your server and running 'em
in a multi-user environment should provide you with a good model. You will
notice that everything is configured in one folder and all required files,
including the RBENGINEXE.CFG and RBENGINEXE.DLL, are also kept outside in
the same folder.
Embedding RBENGINEXE.DLL can create a MAJOR security headache when running
your compiled applications with embedded engine. Running the engine file in
Windows memory may not be an ideal configuration with all Windows Security,
etc.
Here is the explanation regarding the USER name in the RBENGINEXE.CFG file
...
When R:BASE or your Compiled R:BASE EXE is started, if there is no
configuration file found in the path or in the same folder, R:BASE will
create one with a default USER name that is the text format of
YYYYMMDDHHMMSS.
Your application login and user information should NEVER be dependent on the
USER name in the R:BASE configuration file, as this will be the same for
every user. You should consider using the unique logged-in user
(CVAL('NetUser')) to validate the actual logged-in user, etc. There are
additional swift methods to validate users and provide them with appropriate
access to your application menus, functions, etc.
You may also need to verify the SCRATCH setting folder with full access
rights.
Hope that provides you with some blues's clues ...
Fell free to reach out to me with any questions.
Very Best R:egards,
Razzak
