Jim-
I greatly appreciate the reply. The SQL server is completely remote (as in, not on this computer, and not anywhere on my domain/LAN). I was just given an IP address for it. I was also given a specific username and password setup by the admin of that SQL server.
I also don't quite understand what MDB file using ODBC is. I've used access when building DBs from scratch, but I've never done *this* before, and as such I really need broken down instructions.
At the moment I'm somewhat of the belief that the username and password given to me might be incorrect (by the steps I mentioned in my first post).
Yes thats what I think could quite easily be the case too. I rather guessed that given you have an IP address and a user name and password that the sql server wouldnt be on your computer. you'd know about it :) I tried to reply generically in effect to cover a potential range.
The connectivity aspect should be a relatively simple process with UDL ('universal data link' as its called) is merely a text file saved with a udl file extension on your pc that is used to provide the necessary details to connect in line with the method for connection.
A description of that connectivity feature which is the standard built into the ADP format is described numerously on the web but heres a couple of examples here
http://msdn2.microsoft.com/en-us/lib...6(sql.80).aspx
and here
http://www.prezzatech.com/kb/article...on_strings.asp
Connection to SQL server and the ability for you to 'speak' too it comes in a couple of formats in Access you can either use the ADP Project file which is what you are doing, or a standard Access MDB file. This is where, if you chose the MDB method you would be setting up an ODBC connection string in the Control panel of your PC (Start..settings...control panel...Administrative tools...Data Sources) selecting the SQL server ODBC driver and entering a user name and password for a connection which would again be stored on your pc and used to connect to SQL Server by the MDB file.
You can sample this yourself... if you create a simple mdb database and then open it up you would have no tables. (
You have no need for them essentially because the tables are stored in SQL server) you merely would link to any tables by 'Attaching' them to the tables interface screen in Access where they would appear with an icon of a the world globe. You can then query and act on those tables as though they were physically present in your local MDB file database. You can throw the data into visible tables stored locally and so on
(something you can't do with ADP files.)
To all intents and purposes you'd be forgiven for thinking the tables were in Access
as a newbie but they are not in actual fact. Try it out.. when in the database window of an mdb file go to the menubar ..File...Get External Data....Files of type dropdown select ODBC databases ...then select the ODBC connection you created earlier in control panel (and if you didnt you can create one). Access will then ask you if you want to save the connection string in the database. Click Yes and you then see the tables attached as mentioned.
I won't go into the differences between ADP and MDB because basically you could write a small book on it. Suffice it to say they are different, having connectivity features and benefits inherent in one and not the other and vice versa. Most of what you want to do can be done in either of them.
MS favoured ADP files when they were first introduced for communicating with SQL server and to a large extent one could quite easily understand how people invested substantial time programming them using ADO. now MDB files are back in favour again (research Access 2007 you'll understand why) thus making DAO flavour of the month again (as if it ever wasn't... it is powerfully native of Access)
I have only mentioned all of this to make you 'aware', given you are 'newly' connecting with I suspect a 'blank interface' any extra knowledge might give you a clearer understanding of whether or not you have selected the interface 'suitable' for your purpose (whatever that might be long term). None of us know whether MS intend to drop or retain ADP in any future release forewarned is forearmed... so to speak.
Hope this informs you just that 'little' bit better (as for the specific issue currently lets see what your admin person says as to your user name and password it may as you point out simply be wrong)
Regards
Jim :)