Move the name/password out of the database and into a configuration file. The nice thing about that approach is that you just use different configuration files in testing and production, and it will automagically connect to different databases with different logins. Also by centralizing passwords it makes it easier to change the password occasionally.

If you want to have a password that is unavailable to the user running your script, you can make the script setuid and the configuration file only readable to a specific user and group. Whether that makes sense strongly depends upon the specifics of your situation. It does not for me but there are cases where it would be appropriate.