September 20, 2005 at 3:08 pm
Hi,
Is there an easy way to change a linked table from a production DSN to a test DSN? Looks like I have to delete the link from the production DSN and re-add the table from the test DSN. Any ideas?
Thanks,
Bob
September 20, 2005 at 5:00 pm
You can use the linked table manager and select the check box at the bottom that says Always prompt for new location.
September 21, 2005 at 12:54 am
I have never been able to get the Linked Table manager to work with ODBC linked tables as it always halys with an error message.
September 21, 2005 at 1:46 am
September 21, 2005 at 3:53 am
I have a module, tables and forms which will perform this for you dynamically and much easier to use than the linked table manager. If you want it, I will provide it for free just send me a request. You just insert the code into the app and add a couple of lines on your splash, login or main menu forms and it will check the attachments everytime the application starts. Way cool.
September 24, 2005 at 7:49 am
For what it is worth, moving to an .adp as I did just recently makes this far easier. You simply change the connection string from the menu File|Connection...
There are some disadvantages to using the .adp but overall, I believe the advantages outweigh them.
September 25, 2005 at 5:08 am
Thanks I will try this. What exactly is a ".adp" ???
September 25, 2005 at 10:51 am
Sorry, an .adp is a Microsoft Access Project as opposed to a .mdb which is a database. Since you are dealing with sql data, if you have no need of local storage, you can build a project instead of a database. I believe projects started up with Access 2000.
I have just started using .adps instead of .mdbs because there are several advantages. I use Access as a front-end to sql and a project is just that. Any queries you build are saved as either Views or Stored Procedures. I use views and stored procedures now all the time instead of Access queries because they are much, much faster.
Executing stored procedures with parameters is also much easier in a project.
The disadvantages are: no local tables (no big deal if everything is on the sql server anyway), queries are not stored locally but on the sql server (no big deal if you don't have users building their own queries that would just clutter up the sql server if saved there).
Hope that helps,
September 25, 2005 at 11:17 am
Thanks, that helps alot.
Problem is that I am debugging an application developed by another guy and the code is all over the place. There are some local "temporary" tables which I should move to SQL Server. It's a real pain deploying this application to different users when you have local tables.
Thanks again!!
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply