Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
KnooKie
Aged Yak Warrior
623 Posts |
 Posted - 2002-02-21 : 07:11:27
|
| Using Access97, SQL7 and ODBC connections thereinCouple of questions...i) The user initially logs into the database which is great. However if i want call a stored procedure later on in the application i currently have to hard code a pswd into the connection string to avoid a popup login form appearing. I would obviously prefer not to do this, but how ? I can grab the logged on username using the following dll but is there a way to grab the pswd as well ??Declare Function GetUserName Lib "advapi32.dll" Alias "GetUserNameA" (ByVal lpBuffer As String, nSize As Long) As Longii) Is there a way to assign the resultset of the stored procedure(SP) to a combo box list. Can i do (i am currently experimenting) something like this with the LIST propertyMyComboBox.List(SPrecordcount, SPnumberoffields)MyComboBox.AddItem (SPfield1, SPfield2...etc...SPfield5)Will i get any significant gains from populating a combobox with an SP or would i be wiser to just use an access query for ease of use ?? The number of rows in the combo box will be around 200.Any pointers greatly appreciated.Edited by - KnooKie on 02/21/2002 07:14:21 |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-02-21 : 07:33:44
|
| You can create a DSN to use trusted connections instead of SQL Server logins, that would eliminate the need for a password prompt.You can create a pass-through query to call the SP that populates the drop down, then use the pass-through as the row source. If you can't use trusted connections, you can use a fixed login and put the password in the connection string for this query, and then hide the query so that prying eyes won't find it. Since it's just populating a drop down there's no overwhelming need for authentication. You could make up a special SQL Server login with no permissions except to execute SPs just for this purpose.I'd stick with pass-throughs because they are fast and secure, and you don't have to rewrite your Access app if you need to change the procedure behind it. |
 |
|
|
KnooKie
Aged Yak Warrior
623 Posts |
Posted - 2002-02-21 : 08:27:59
|
| thanks Rob, yeah unfortunately trusted connections are a bit tricky as the DSN is also used in another front-end which it's needed in. Like the idea of a special login though, that'll fit the bill nicely.I'll experiment with pass-throughs.congrats on reaching 3000 posts by the way Paul |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-02-21 : 08:47:56
|
 Thanks!I just remembered that you can build an ODBC string that does not require a DSN at all, you need to include the Network and Address:ODBC;Server=servername;Network=DBMSSOCN;Address=123.123.123.123,1433;UID=username;PWD=passwordI'm not sure how the trusted connection parameter is set, but you should be able to find it in the DSN settings in the registry or file DSN.The Network library is DBMSSOCN, which is TCP/IP. The Address MUST include the IP address or machine name of the server, and the port it listens on, which is usually 1433.Now you can put something like this in your pass-through queries and have different settings than the DSN you're currently using. You can also set options for MachineID and such that will help you identify which query is being used; these are accessible in SQL Server with the HOST_NAME() and HOST_ID() functions. These can be checked to prevent illegal access via a phony pass-through call. |
|
|
|
|
|
|
|
|
Using stored Procedures for row sources