How to dynamically validate users at run time using connection pools ?

Question

Hi Folks
We are facing a peculiar situation . We have established connection to our
oracle 8i database using Oracle Thin driver using conenction pooling at the weblogic
server . We set up connection pools at the console to set up connections to thge
oracle 8i database. However the user name and password is always static when
we create the connection pool at the console .
How do i dynamically validate other users using the same connection pool ??
Eg - The connection pool at design time in the console uses user A and password
- passA . Now at run time lets say I prompt the user for a login screen and want
to trap the user id and apssword parameters entered by the user and use it with
the connection pool created earlier . I tried using the below code snippet :-
Properties props = new Properties();
props.put("connectionPoolID", "Oracle_Thin_Driver_Pool");
props.put("user" , userId );
props.put("password",userPass);
myDriver = (Driver) Class.forName("weblogic.jdbc.pool.Driver").newInstance();
conn = myDriver.connect("jdbc:weblogic:pool", props);
But always it connects to the database using the userid and password set in the
console while creating the connection pool . So how i get the connection pool
to validate my current userid and password entered through the login screen ??
Thanks in advance
Keith

Answer 1

Hey Bob.
So I assume you're -completely- working with built executables?  You're not going to work in the editor environment to modify your projects at all?
If this is the case, then having a generic deployment phase at the beginning of the executable (with a "setting up hardware for your app" splash screen) isn't a bad idea -
Check the binary on the target, ensure it matches the binary you have on the host machine (in case you ever decide to update).
If they don't match, FTP the new file down to replace the old one.
FTP the ni-rt.ini file, ensure the startup exe is enabled and is pointing to the correct location.  
If it's not enabled or not pointing to the correct startup file, modify the .INI file and FTP back to the target.
If you had to update the INI file, ask target to reboot itself.  Wait 30 seconds, and wait for target to become available again.
Connect to the target. If you cannot connect, reboot target.  If the target comes back and you still cannot connect to the app, notify user.
That's almost exactly how we handle installation and deployment via MAX.  
The big assumption here is that the built executables were all built with the same version of LabVIEW Real-Time.  If not, you'd need a system replication step in there to make sure the proper version of LabVIEW is on the target before launching the built .rtexe.  
-Danny