user rights - odbc

Andreas Lommel <him_lommel@t-online.de> wrote in message news:37ccec65.8622768@news.btx.dtag.de... > The task: A user has access to a table (update, select, insert) via a > program. > This user also should have only select-rights via odbc on a table in > the same database. > How can it be done ? > Adreas, I had a similar problem. In my case, the programs that access the database run locally, and the client front-end communicates with these programs via a tcp port. I set up the instance with stream-pipe connection (ipcstr). I then set up another instance with both network (onsoctcp) and stream-pipe connections, so this instance can be accessed via ODBC. For the small number of tables that the users wanted to be able to read with ODBC I created views in a small database in this secondary instance that access the tables in the original instance. (The two instances can communicate via the stream-pipe connection.) I'm actually using joins, which effectively prevents any updates. If you want one-to-one views set up for tables, you should still create a join with perhaps systables, where tabid=1. This should make all your views read-only. The secondary instance can be very small, as it does not need to have any data in it, just make sure that the database you create has the same logging mode as the one you access through it. Cheers, Gabor Heppes

The task: A user has access to a table (update, select, insert) via a program. This user also should have only select-rights via odbc on a table in the same database. How can it be done ?

Andreas Lommel wrote: > > The task: A user has access to a table (update, select, insert) via a > program. > This user also should have only select-rights via odbc on a table in > the same database. > How can it be done ? The program runs as, or at least connects to the database server as, another user who has the proper permissions to modify data in the table. The user's own login does not have such permissions. The only rub to this is if you are trying to capture the real user automatically for audit purposes since anyone running the priveleged application will have the same username/userid. The special app will have to manually maintain the user fields in data and/or audit tables with the captured real user's identity so the defaults do not put the dummy user there. Art S. Kagel