OK, merlyn makes a point that the exe (that you want to store user/pass in) can still be reverse engineered so it still is insecure. Good point, but lets presume for the moment that an intruder has not gained shell access to your box- yet.

Without doubt there are windows exploits that permit malicious types to view the sourcecode of your script - thus hardcoding the username and password in there is a bad idea - IF the database is accessible from the web - which if it is being called solely from a CGI or such - should not be the case. The sensitive database ought to be accessible from localhost(127.0.0.1) and possibly trusted hosts on a local network. Certainly NOT from the net in general.

So lets presume now that your server has been (owned/rooted/admin'd/crackered/whatever) invaded, well then the invader has access to your script source, hence can find the executable you are getting the user/pass from, hence can run that executable to glean the user/pass. This only adds one step for the invader, and a pretty simple one at that. Reading the user/pass from a properly permissioned file might be a better way, but I suppose that if your script can have read permission on it - then any would be invader could do the same. Windows monks prepare to flame me ....now but short of changing to a platform with (cough) fewer simple and (cough) obvious exploits - you're still up the security creek in a barbed wire canoe