From: reb01501@NOSPAMyahoo.com   
      
   Ulrich Achilles wrote:   
   > (@somedate is a monday and the view selects the courses that are   
   > actual for that week).   
   >   
   > Of course I found soon that it is not possible to pass parameters to a   
   > view in SQL server.   
      
   An Access parameterized view is exactly the same as a simple SQL Server   
   stored procedure, except the procedure is not directly updatable. That,   
   however. is not a great loss since there is no frontend to SQL Server that   
   does everything that Access does for Jet databases. The front end for a SQL   
   Server database needs to provide all the functions provided by Access. This   
   typically means retrieving read-only data from the database (to avoid   
   locking problems) and passing parameter values to a stored procedure that   
   performs updates, inserts and deletions as needed.   
      
   > As a solution I created a table "parameters" with   
   > just one row to hold the parameter and joined it to the courses-table:   
   >   
   > I came across that construction in the net, but it was commented as   
   > horrible, ugly and so forth.   
   >   
   > My question: Is it really that bad? And why?   
      
   Yes, it can be. There are so many things that can cause problems.   
   Client crashes can leave bad parameter values in the table.   
   Multiple users can be using each other's incorrect parameter values.   
   Mainly, it's bad because it's outside of the developer's control (assuming   
   that users are entering values into it).   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)