SELECT DISTINCT
dbo.Webs.FullUrl,
dbo.WebGroups.Title AS [Group],
dbo.WebGroups.Type,
dbo.UserInfo.tp_Title
FROM dbo.Webs
RIGHT OUTER JOIN dbo.WebGroups
INNER JOIN dbo.WebGroupMembership
ON dbo.WebGroups.WebID = dbo.WebGroupMembership.WebID
AND dbo.WebGroups.ID = dbo.WebGroupMembership.GroupID
INNER JOIN dbo.UserInfo
ON dbo.WebGroupMembership.MemberID = dbo.UserInfo.tp_ID
ON dbo.Webs.SiteId = dbo.UserInfo.tp_SiteID
AND dbo.Webs.Id = dbo.WebGroups.WebID
WHERE (dbo.Webs.FullUrl LIKE N'%sites%')
and dbo.Webgroups.Title = 'Administrator'
ORDER BY dbo.WebGroups.Title

Please do not query the SharePoint database directly; use the SharePoint
API.

can you show me what that query would look like via the api?

I can see using the OM to INSERT, UPDATE, DELETE but SELECT commands dont lock
anything, am i wrong? is there some other implication?

i have a ton of sql queries and if there was some sort of simple way to do these
calls via the api, i would be interested for a small example or maybe the before
and after of something just to see how its done... or maybe my google skills
just havent brought me to the right place.

From the hip:

1. Database locking potentially caused by your non SharePoint queries.
2. Competition for other database resources like connections, threads,
etc.
3. The likelihood that the SharePoint content database will change over
time (it changed with SP1 and with SP2).
4. Loss of SharePoint business logic built into the API.
5. Loss of SharePoint security built into the API.
6. Loss of SharePoint data validation (very little RI in the database).
7. Subtleties in the schema that may not be fully understood.

Some other people's comments:
blogs.msdn.com/.../404802.aspx
blogs.msdn.com/.../496759.aspx
bobmixon.xwiki.com/.../MigratingFromSharePointV2T
oV3
blogs.msdn.com/.../508377.aspx
andrewconnell.com/.../1788.aspx
etc...

give him a break dude! he just needs distinct site Admins.

he will fix his query too later.