this *is* a bug, and if so, what resolutions, work-arounds or patches might
be available:
Dejan Sarka reported a bug in visio to Microsoft in 2002.
The issue was reverse engineering a SQL database, with objects owned by
non-dbo users. visio would then give the following error:
Error! Cannot extract column definition for the table/view 'TestTable'. The
definition is not available or you may not have sufficient privileges.
Please check with your database administrator.
This happens, even though integrated security is used (or SA for that
matter). Privleges is not the issue (if we do a little *hrm* update of
sysusers, so that dbo owns the table, everything is fine).
Dejan (or others): Do you know of a resolution to this issue?
Here is a googleref:// to the specific post:
[url]http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=Xns92C05A65D23
20dussanemailcom%40207.46.239.39&rnum=2&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-
8%26oe%3DUTF-8%26q%3D%2522Error[/ url]!%2BCannot%2Bextract%2Bcolumn%2Bdefi
nition%2B
for%2Bthe%2Btab
le%252Fview%2522%2Bvisio%2B
Thank you!
-IngeHi Inge,
Thanks for your post. According to your description, I understand that you
want to verify if this issue is a BUG. The issue was reverse engineering a
SQL database, with objects owned by
non-dbo users. visio would then give the following error:
Error! Cannot extract column definition for the table/view 'TestTable'. The
definition is not available or you may not have sufficient privileges.
Please check with your database administrator.
If I have misunderstood, please feel free to let me know.
Based on my research, this is a known issue of Visio. The gist of this
known issue is the tables which are owned by objects other than the DBO
object are NOT Reverse Engineered by Visio. The resolution of this problem
is changing ownership of the Tables and other objects (Stored Procedures,
etc.) so that the DBO is the owner. The cause of this problem is that Visio
is unable to Reverse engineer Tables which are not owned by the DBO object.
Thanks for posting in the community.
Best wishes,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.|||Sorry, but Inge is right, this is a bug. If Vision can reverse engineer only
objects owned by dbo, then it should not give you the possibility to select
any objects not owned by dbo through UI. And this should be
documented.Otherwise it is simply a bug, which should be corrected. And a
simple hint: check the sp_MShelpcolumns system SP, which is called by Visio
during the reverse engineering. IMO visio is a produc good enough to
deserve proper care.
Thank,
Dejan Sarka, SQL Server MVP
Please reply only to the newsgroups.
""Yuan Shao"" <v-yshao@.online.microsoft.com> wrote in message
news:a5ut15g5DHA.4028@.cpmsftngxa07.phx.gbl...
quote:
> Hi Inge,
> Thanks for your post. According to your description, I understand that you
> want to verify if this issue is a BUG. The issue was reverse engineering a
> SQL database, with objects owned by
> non-dbo users. visio would then give the following error:
> Error! Cannot extract column definition for the table/view 'TestTable'.
The
quote:
> definition is not available or you may not have sufficient privileges.
> Please check with your database administrator.
> If I have misunderstood, please feel free to let me know.
> Based on my research, this is a known issue of Visio. The gist of this
> known issue is the tables which are owned by objects other than the DBO
> object are NOT Reverse Engineered by Visio. The resolution of this problem
> is changing ownership of the Tables and other objects (Stored Procedures,
> etc.) so that the DBO is the owner. The cause of this problem is that
Visio
quote:
> is unable to Reverse engineer Tables which are not owned by the DBO
object.
quote:|||The bug is in Visio's use of the database stroed procedure
> Thanks for posting in the community.
> Best wishes,
> Michael Shao
> Microsoft Online Partner Support
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
>
sp_MShelpcolumns.
A work around is to modify the stored procedure witht he following
code after the "as":
--Visio Bug Fix db(2/25/2004)
declare @.myTableOwner varchar(64)
select top 1 @.myTableOwner=u.name from sysobjects s, sysusers u where
s.uid=u.uid and s.name=@.tablename
set @.tablename = @.myTableOwner + '.' + @.tablename
--
Note that it will only work if table names are unique. Otherwise it
will only return information on the first instance of that table.
v-yshao@.online.microsoft.com ("Yuan Shao") wrote in message news:<a5ut15g5DHA.4028@.cpmsftng
xa07.phx.gbl>...
> Hi Inge,
> Thanks for your post. According to your description, I understand that you
> want to verify if this issue is a BUG. The issue was reverse engineering a
> SQL database, with objects owned by
> non-dbo users. visio would then give the following error:
> Error! Cannot extract column definition for the table/view 'TestTable'. Th
e
> definition is not available or you may not have sufficient privileges.
> Please check with your database administrator.
> If I have misunderstood, please feel free to let me know.
> Based on my research, this is a known issue of Visio. The gist of this
> known issue is the tables which are owned by objects other than the DBO
> object are NOT Reverse Engineered by Visio. The resolution of this problem
> is changing ownership of the Tables and other objects (Stored Procedures,
> etc.) so that the DBO is the owner. The cause of this problem is that Visi
o
> is unable to Reverse engineer Tables which are not owned by the DBO object
.
> Thanks for posting in the community.
> Best wishes,
> Michael Shao
> Microsoft Online Partner Support
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
