(Not sure what you mean either.)
"Only once" ? Passwords and permissions within the server/db change all the time. The password should be provided each time the app is launched.
For a pure client-side app, store the connection parameters PLUS the database version it runs against (Not product version, but app version) in the app, not the db. That means a small file on the users C: drive. Never store the password, always ask for it. When the app is launched it picks up the parms from the file, asks the user for the password, and connects. Once connected, it checks that the app version matches the db version (else abort).
Once you have that running, you can support connections to different environments of the db (Prod, UAT, Test): store them all in the same local file; when launched, provide a drop-down and let the user choose which environment they want, then the password.
This allows:
• client app v1.0 (distributed to all users) to run against db v1.0 for production
• client app v1.2 (distributed to UAT testers only, but they then have two apps sitting on their desk top connecting to two dbs, and we do not want mixups, do we) to run against db v1.2 for UATesting
• client app v1.3 (on the developers desktop, etc) for Dev
• if the app team provides the v1.3 prototype to a couple of users, accidentally conecting to the wrong db is prevented
• all db versions to be on the same or different servers (connection string)
If you have a different sort of app that always connects and uses the db, but the connection parms and "provided only one", such as a licensed monitoring product, the above still applies, but you do not have to worry about versions or environments (there will be only line line in the file). However, the password becomes the problem; if you store it, you have to encrypt the file, which means linking encrypt/decrypt libraries into the app.