You need to follow the advice given by JamesNC here. Check the documentation - SQL Server Books Online is a good place to start. Test your connection using the the ODBC Administrator or the MSSQL query analyser - in either case make sure you select "SQL Server Authentication" (rather than "Windows Authentication") and enter the username/password you have been given by the remote site.
If the remote site's SQL DBA can't or won't help you with a username/password, you're pretty much stuffed - if neither of you know what you're doing, it'll only lead to more problems. The SQL Server Enterprise Manager makes tasks like adding a user pretty easy, but it's something the admin at the remote site will have to do. In any case, you don't need the help of Perl Monks. Try a Google search for "Enterprise Manager Tutorial".
In fact, I don't think either of these issues are really your problem. If the customer can't configure their system for you to access them, it's not your responsibility - they need to pay somebody with SQL DBA experience to help them out. If you help them on this, they'll be back to you for free DBA advice every five minutes till the end of time. This is a lesson I learned the hard way, and perhaps saying it here will ease the journey of a fellow monk.
As a side-note, I'm quite alarmed by the description of what you're trying to do you have given. It's an extremely bad idea for your customer to expose their SQL Server to the public internet on its default port (1433) - just search Google for "Code Red worm". Your customer needs to look into securing the server somehow - it may be as simple as adding a rule on the firewall to prevent connections to the SQL server from anywhere but your IP address.
|