|
[x]
Posted via EE Mobile
|
|
| Search, ask, and monitor your questions on the go with EE Mobile. Visit Experts Exchange from your mobile device and never be out of touch again. |
|
|
|
|
|
[x]
The Solution Rating System
|
|
| With so many solutions, how can you tell which solutions are most likely to help you and which ones are not? To provide you with a tool to use, we rate our solutions based on various elements that most accurately determine if a solution is a quality solution. To explain what factors affect the solution rating, here are the elements we take into consideration when formulating our solution rating. - The Grade of the Solution
- The Zone Rank of the Expert Providing the Solution
- The Number of Author and Expert Comments
- The Number of Experts Contributing
- The Feedback of the Community
Your Input Matters
Because of the way the system is set up, the most important variable in this equation is you. As a member of Experts Exchange, you are able to cast your vote on the quality of the solutions in regard to how complete, accurate, helpful and easy to understand each solution is. When you provide your feedback, each rating is adjusted accordingly. So, if you see a solution that has a poor rating that you think is a good solution, let us know by rating it. As you do, the rating will be adjusted and will become more accurate for other members of our site. If you have any suggestions that you would like to make for our rating system, please ask a question in the Suggestions Zone of Community Support. Thank you! |
|
|
|
|
Asked by Natchiket in Microsoft Access Database, Access Coding/Macros, Access Forms
Due to a recent 'crackdown' in IT security all Access databases which connect to company servers must not have server passwords embedded in the connection string of attached tabledefs and stored querydefs. With regard to tabledefs this is straightforward as the tables can simply be re-attached without dbAttachSavePWD as part of the attributes property.
However, since querydefs don't have an attributes property this appears to be more problematic. For stored querydefs it seems that the only solution is to set the connection string to the DSN (or at least leave out the password) and then open one querydef
to force the default Login prompt to appear. Once the user has successfully applied the password Access caches it and then subsequent querydefs opened on the same DSN automatically have the password applied.
This raises a problem of automation control, because it would be nice to capture the password in an Access form and then supply it to the dialogue box automatically, however this raises the prospect of the dreaded sendkeys and what to do if the user supplies the wrong password. Can anyone suggest either a neat solution or an unequivecal statement that only temporary querydefs can be used in this situation.
20091111-EE-VQP-91 - Hierarchy / EE_QW_3_20080625
