main logo
Subject: Re: Client/Server, what to do with .dbc?
Author: Mike Devlin
Posted: 2002/10/25 09:50:58
 
View Entire Thread
New Search


<i><font color="#663300">
Unfortunatly, you can't share this connection with the views in 7.0.
</font></i>

I am still using VFP 6, so...

<i><font color="#663300">
Ok, so far so good. But, your best bet is to create the views on the connection rather than the data source. This lets you use more than one data source by changing the connection.
</font></i>

Done. So now the connection userid and password is blank, just what I am looking for.

<i><font color="#663300">
OK, this is good. Once you do this, then you can use CursorGetProp('ConnectHandle') and store that to your app object. (For SPT stuff)
</font></i>

This is being done. I use the handle in instances when I need to do SQLEXEC and the ilk.

<i><font color="#663300">
This wouldn't happen if you had set the two views to 'share connection'.
</font></i>

Thanks for the heads up on that little tab. I never knew that the advanced options option existed.

<i><font color="#663300">
What I do is open a remote view, which is a select of my config table. I set the config properties in my app object and leave this view open. I grab the handle of this view and store it to an app property. This view stays open until the CleanUP code where I close it.

The above works well. If you don't want the user to get the second 'oracle connect login' you should be able to build a connect string, open the view adding it to the USE command. In the connect sstring you can put the userid and password. This way, they are never stored to the DBC.
</font></i>

This I understand. I have set a few views to 'share connection'. Once one is opened they all open. The problem now is that first Oracle ODBC Driver Connect dialog. It seems pretty cheesy. What I would love to do is feed the Oracle ODBC Driver the userid and password from the CodeBook login.

<i><font color="#663300">
Also, if you do this, you are never writting to the DBC, and you can include it in the .EXE if you want. Or, if you want to allow multiple data sets, you can just give every user a local copy of it.
</font></i>

So, I now know that I can avoid storing the userid and password in the connection, as long as I use the Oracle ODBC Driver Connect dialog to login by opening a base user remote view (a view all users have the rights to select from) that will remain open throughout the application, allowing all future views opened in this session of the application to share its connection. Then use the CURSORGETPROP to capture the connection handle of this view for use in any other SQLEXEC type activities.

Thank you very much for the help. If you have any suggestions please feel free to continue expanding my horizons.

Mike D
Devman
mdevlin .at. ajdebruin .D.O.T com

 
©2002 Mike Devlin
<-- Prior Message New Search Next Message -->