Updateing SQL views via TDBGrid

Hi, meikl.
Yeah, so why Microsoft developed trigeers "INSTEAD OF" why allow operation other then select on views?
But the big question is what about permissions, I can set insert, update, delete permissions on view but it's useless untill i set same permissions on source table, what about more complex views with joins or nested views?
maybe its normal but for me its not logical :)

Second thing, imagine that situation:
I have a table with data about some products, theres column identifying product.
First idea that comes to my mind is to create few views, each view would correspond to some product
than I could simple allow users to work on views, but i cant because even if i create trigger (to fill column identifying product)
this trigger will nver be called.  

ziolko.

>But the big question is what about permissions, I can set insert,
>update, delete permissions on view but it's useless

usual this permissions are not useless,
but depending on your role-concept

if you try this as owner of view and table, then yes, it has no affect
(the owner can usual all)

>I have a table with data about some products, theres column identifying product.
there is no trigger needed, except you want to update/insert,
its just a view based on a joined select

guess you are new to sql-database-concepts?

meikl ;-)

>guess you are new to sql-database-concepts?
 
heh, no I'm not new:)
in matter of fact im into databases for sometime now:)
I'll try to be more clear here.

>there is no trigger needed, except you want to update/insert,
>its just a view based on a joined select

I've never used views to update/edit data, always stored procedures, hell I've never used TDBGrid:))
Just yesterday I tried to show someone "hello world" program with ADO and I was suprised by what i saw.

>usual this permissions are not useless,
>but depending on your role-concept

if You give user permission to insert records to view, but not to source table it is useless because eventually user wont be able to insert new records:)

ziolko.

>if You give user permission to insert records to view, but not to source table it is useless because
>eventually user wont be able to insert new records:)
yep, of course, i saw it from the other direction :-))

well, what is your question already?
(i missed it in the meanwhile)

meikl ;-)

Is there a way to "force" insert/update on view not table?:)

ziolko.

..of course by useing combination of ADOQuery, Datasource and DBGrid:)

btw. I'm afraid I know answer, and that answer makes me very dissapointed :))
ziolko.

>Is there a way to "force" insert/update on view not table?:)
no, because a view is not something physical
on which could be stored additional things,
which are not based on the physical tables

what is your intention to do so?

meikl ;-)

my intention is simple... I wanna see if it's possible:))

ziolko.

>I wanna see if it's possible:))
in this case, based on a view on serverside -> no

of course there are some workarounds
(clientdataset, memorytable, etc)
where you can cache new data before they are (or not) forwarded to the server

meikl ;-)

genaraly my point is...
if I can use: update My_View....  then why TDataSource is so stubborn and keep using: update My_Table...
maybe I'll write TMyDataSource?:)

ziolko.

this doesn't do the TDataSource,
this does ADO for you

meikl ;-)

appendix:

>this doesn't do the TDataSource,
>this does ADO for you

respectivly also the sql-server self

:-))

right -  ADO :)

p.s. I'll keep this open for a while maybe someone else will be interested in shareing his thoughts about this ADO behaviour, then I'll grant You with points... even thou You got plent of them :))

ziolko.

:-)) is ok

as I said, points are Yours:)

ziolko.