Column level permissions

Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
edited April 15, 2004 11:27AM in SQL Compare Previous Versions
Hi Kevin,

There was a problem with column-level permissions in version 3.1. The
symptom of the bug was an index out of range error, but I suppose there
could be different side-effects depending on the circumstances. If you
haven't got the latest version, 3.1.5, then by all means check for updates
and see if it has been fixed. If you've already got 3.1.5, please get back
to us.

Regards,

Brian Donahue
Red Gate Technical Support

"Kevin Conklin" <kconklin@nospam.org> wrote in message
news:RHYfgxuIEHA.1240@server53...
> I'm having the following problem with column level permissions. Two
> identical tables are being flagged as different, based on column level
> permission, when the permissions set are actually identical. The tables
> being compared have 'SELECT, INSERT & DRI' permissions set at the table
> level, and 'UPDATE' permission set on a single specific column. SQL
Compare
> correctly identifies the column with permissions set in one of the
> databases, but not in the other. For the problematic table it scripts a
> GRANT UPDATE, but on the wrong column.
>
> Are there any known issues concerning column level permissions comparison,
> and if so, is there a workaround/ETA on a fix? Thanks in advance!
>
> --
> Kevin Conklin, MCP
>
> To reply via e-mail, replace 'nospam' with 'heritagechristianservices'.
>
>
· Share on Twitter

Comments

  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Hi Kevin,

    Would it be possible for you to send us a SQL script of the tables,
    including the permissions, by generating a SQL script in Enterprise Manager?
    Please send it to support@red-gate.com.

    Thanks!

    Brian Donahue
    Red Gate Technical Support

    "Kevin Conklin" <kconklin@nospam.org> wrote in message
    news:07wndDvIEHA.1616@server53...
    > Thanks for the quick reply, Brian. I'm running the latest version.
    > (3.1.5.191)
    >
    > Kevin Conklin
    >
    >
    > "Brian Donahue (Red Gate)" <brian.donahue@red-gate.com> wrote in message
    > news:DdhRC7uIEHA.1236@server53...
    > > Hi Kevin,
    > >
    > > There was a problem with column-level permissions in version 3.1.
    The
    > > symptom of the bug was an index out of range error, but I suppose there
    > > could be different side-effects depending on the circumstances. If you
    > > haven't got the latest version, 3.1.5, then by all means check for
    updates
    > > and see if it has been fixed. If you've already got 3.1.5, please get
    back
    > > to us.
    > >
    > > Regards,
    > >
    > > Brian Donahue
    > > Red Gate Technical Support
    > >
    > > "Kevin Conklin" <kconklin@nospam.org> wrote in message
    > > news:RHYfgxuIEHA.1240@server53...
    > > > I'm having the following problem with column level permissions. Two
    > > > identical tables are being flagged as different, based on column level
    > > > permission, when the permissions set are actually identical. The
    tables
    > > > being compared have 'SELECT, INSERT & DRI' permissions set at the
    table
    > > > level, and 'UPDATE' permission set on a single specific column. SQL
    > > Compare
    > > > correctly identifies the column with permissions set in one of the
    > > > databases, but not in the other. For the problematic table it scripts
    a
    > > > GRANT UPDATE, but on the wrong column.
    > > >
    > > > Are there any known issues concerning column level permissions
    > comparison,
    > > > and if so, is there a workaround/ETA on a fix? Thanks in advance!
    > > >
    > > > --
    > > > Kevin Conklin, MCP
    > > >
    > > > To reply via e-mail, replace 'nospam' with
    'heritagechristianservices'.
    > > >
    > > >
    > >
    > >
    >
    >
    · Share on Twitter
This discussion has been closed.