Rick -
Thanks for checking that. I should've done it myself. Sorry I didn't
respond when you asked for confirmation.
Ross
On Thu, Feb 01, 2001 at 05:38:12PM -0500, Rick Delaney wrote:
> Rick Delaney wrote:
> >
> > "Ross J. Reedstrom" wrote:
> > >
> > > This is a bug that was fixed in 7.1beta f
Rick Delaney wrote:
>
> "Ross J. Reedstrom" wrote:
> >
> > This is a bug that was fixed in 7.1beta for sure, but also 7.0.3,
> > I believe. So it's as simple as upgrading.
>
> Thanks, I'll upgrade. I couldn't find this listed in any changes files
> so can you (or anyone) confirm that this is fi
"Ross J. Reedstrom" wrote:
>
> This is a bug that was fixed in 7.1beta for sure, but also 7.0.3,
> I believe. So it's as simple as upgrading.
Thanks, I'll upgrade. I couldn't find this listed in any changes files
so can you (or anyone) confirm that this is fixed in 7.0.3?
And does fixed mean
This is a bug that was fixed in 7.1beta for sure, but also 7.0.3,
I believe. So it's as simple as upgrading.
Ross
On Thu, Feb 01, 2001 at 10:09:29AM -0500, Najm Hashmi wrote:
> Hey Rick,
> I am sure there are more elegant solutions but I have a simple
> one. Write a trigger that wil
The problem is fixed in the 7.1 beta series.
Rick Delaney wrote:
>
> I'm using 7.0 and have noticed that I need to grant SELECT and UPDATE
> permissions on any referentially-related tables. Can/should I get
> around this? A somewhat contrived example:
>
> CREATE TABLE emp (
> id integer PRIM
Hey Rick,
I am sure there are more elegant solutions but I have a simple
one. Write a trigger that will grant the permissions before insert or
update and and revoke all privileges after the insert or update.
-Najm
Rick Delaney wrote:
> I'm using 7.0 and have noticed that I need to gr
I'm using 7.0 and have noticed that I need to grant SELECT and UPDATE
permissions on any referentially-related tables. Can/should I get
around this? A somewhat contrived example:
CREATE TABLE emp (
id integer PRIMARY KEY,
salary integer
);
CREATE TABLE proj (
id integer PRIMARY KEY,
emp_id
