views:

46

answers:

1

I have an Access 2003 project in which all data is stored in SQL Server 2008. I am using ADO to view/update data via forms that are completely unbound. For example, a form has several textboxes and combo boxes on it. When the form is loaded I use ADO to make a call to a stored procedure on SQL SQL, it returns a recordset and I populate the controls, via VBA, with the data from the recordset. I like this approach because only the VBA is stored within Access. No data (well actually connection strings are stored in Access, but that is it!).

My problem is what to do when it comes to reports. I want to create reports that are based off of views created within SQL Server, however I would like to avoid, if possible, static linking to the views directly from within Access. Is it possible to set the recordsource of a report dynamically at run-time to be the results of a SQL Server view? If it is, how does one go about designing the report id Access does not contain any data?

More info ... The reason I want to avoid linking to the view in Access is the environment in which the Access application could be run changes (Production, Development, Test). Currently whenever I make any calls to the database stored procedures, I look up the connection string (Active Directory based so no passwords are stored) in the only table that is stored in Access .

Thanks for any assistance.

+2  A: 

First of all let's be clear: you don't have an Access 2003 "project." You have an Access 2003 database.

An actual Access Data Project cannot have local tables, and uses a SQL Server as the back end. When you view Tables you see the ones that exist on the server, and under Queries you see the views, functions, and stored procedures that exist on the server. You can use the "Upsize Wizard" to turn an Access database into an Access data project (or probably better, just create a new ADP (Access Data Project) and import all the forms, reports, macros, and modules.

Here are my ideas:

  1. Convert the database to an actual Access Data Project and then just use regular old queries as if they were addressed to the local database. You can even bind forms to stored procedures and they can be updatable. To deal with Production, Development, and Test, you just change the connection string in the GUI or you change it through code like so:

    Application.CurrentProject.CloseConnection
    Application.CurrentProject.OpenConnection NewConnString
    

    If you want to read the connection string from a centralized database or from a text file on a share or from a common table you load in each environment (that has the connection information for every other environment), that is up to. I have one Access Data Project that has an toolbar with an Environment dropdown. When the environment is switched, a child database dropdown is then populated, and finally all open forms are notified by an event (though bound forms close when this occurs).

  2. There's nothing wrong with using linked tables. Just write a procedure that loops through all the tables and updates them to point to the correct server when you want to change environments. The difference between "static" linking and "dynamic" linking is just a single VB procedure that rips through all the tables and relinks them--easy peasy.

  3. Setting a report recordset dynamically at runtime is problematic. It MIGHT be possible in actual Access Data Projects, but definitely not in regular MDBs.

  4. You CAN create pass-through queries in an Access MDB, but I'm not sure about passing parameters in. You'd probably have to set the query text dynamically with the parameters hard-coded and then run the report. This would be a problem for a multi-user database unless each person gets his own front-end to run from.

I recommend that you go with option 1 or 2. Option 1 seems simplest but there is some learning to do before you'll become facile with ADPs over MDBs. Let me know if you think you'll go down that route and I I'll share some of the gotchas with you. However, it's probably easier than what you're doing now which is everything manually. (Ouch!) The second option would be fastest for implementing right away and not throwing any wrenches into your current skill with MDBs.

UPDATE

So if you want to link tables, here's some code to get you started:

Sub TableRelink(MdbPath As String)
   Dim Table As DAO.TableDef
   Dim Tables As DAO.TableDefs
   Set Tables = CurrentDb.TableDefs
   For Each Table In Tables
      If Table.SourceTableName <> "" Then 'If a linked table
         Table.Connect = ";DATABASE=" & MdbPath 'Set the new source
         Table.RefreshLink
       End If
   Next
End Sub

This code is for MDB files, but some digging will quickly give you the correct properties and values to use for SQL Server linked tables.

Another Thought

I just thought of another possible way to handle just the problem you're experiencing: Use a session-keyed "temp" table in Access. Create a local table that has all the columns the view returns, plus a GUID column. When the report is run, insert the contents of the view to the local table, keyed by a new GUID value. Set the recordsource of the report to SELECT * FROM MyViewTempTable WHERE GUID = '{GUID}'. Simple problem solved. On report_close, delete from the table. Perhaps put in a date also and delete after 10 days in case any rows get left behind.

Emtucifor
ADPs have more or less been dropped by Microsoft, but it is possible that they will be revived some time in the future. Access 2010 only provides limited support for ADPs (http://technet.microsoft.com/en-us/library/cc179181.aspx). I think option 2 is the best bet.
Remou
For someone who is using Access completely unbound, an ADP should be a huge improvement, seems to me, even if it's de facto deprecated -- the original questioner is not using recommended practices to begin with, so it seems to me that going with ADP would be a step up.
David-W-Fenton
I have no problem using linked tables. Up to this point there has been no need for them. All data access is done via stored procedures. Certainly bound forms and controls have their place but not in this application. There is no concept of paging through the data record by record, which we the only reason to use bound forms. ADP projects are deprecated and prevent a security risk. I do not want users to have anyway of creating their own "stored procedures" from within Access and that is a risk that an ADP could allow.
webworm
An ADP would not allow anything of the sort, unless you've completely bollixed up the security and roles in your SQL Server!
David-W-Fenton