[EMAIL PROTECTED] wrote:
I was blocked from running a SELECT query against secrettable. I could
INSERT values but not DELETE them. I reason that this is because DELETE
... WHERE ... requires a SELECT to be run on the table to identify the
rows to get rid of. The error I got when trying to delete
Yes, I think that _may_ solve your problem. Try granting only INSERT and
UPDATE on the table then grant only SELECT permission on the ID column (I
assume it's autoincrementing?) and the user_id column. If you don't make
the user_id column visible, how will you ever discover the correct ID to
up
Sorry to reply yet again, but I think I have the solution. After doing all we
have said above I added
grant select(ID_Num) on sampdb.secrettable to 'user'@'localhost' identified by
'password';
and of course updates and deletes are done via
update secrettable set secretinfo="blah" where ID_Num
Thinking about this some more, it might be possible to achieve what my last
email suggests by allowing select on the primary key column. Or would that
set us back again? Thoughts?
Todd
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lis
On Monday 30 August 2004 4:08 pm, [EMAIL PROTECTED] wrote:
> I think that INSERT-only would be as good as we could hope for as I have
> been having a very hard time trying to think of a valid business reason
> why a user would be allowed to either UPDATE or DELETE rows from a table
> where they
I think that INSERT-only would be as good as we could hope for as I have
been having a very hard time trying to think of a valid business reason
why a user would be allowed to either UPDATE or DELETE rows from a table
where they weren't allowed to even see the data. However I can think of
sever
> GRANT usage on samp.* to 'permtest'@'localhost' identified by 'password';
> GRANT insert, update, delete on samp.secrettable to
> 'permtest'@'localhost';
> GRANT select, insert, update, delete on samp.Account to
> 'permtest'@'localhost';
>
This worked much better for me, though it's not a per