What do columns with a "dot" mean when listing Sql Server user permissions using sp_helprotect? I have a DB that I did not setup and I used sp_helprotect to list the permissions, the output is as in the image below.

I don't understand the dot's in the Owner, Object and Column columns.  And I can't find a similar example in the few db's I have.

What to they related to or what do they mean?  I assume not applicable or the like, is that correct?  

And how can I set permission like this on another DB ... I'm trying to setup another db with a user that has the same permissions.

.
Stop using sp_helprotect - it's bad news, mostly because it hasn't been updated since before SQL Server 2005 was released. Instead, you can generate the script you need based on sys.database_permissions and possibly sys.database_role_members. For example, let's say you have a user named foo and you want to apply the same permissions as foo to a new user you just created, bar. You can see the permissions foo has (at least for the database itself, tables, views, columns, procedures and functions) and the role(s) they're in using the following script:

DECLARE @pid INT;

SELECT @pid = principal_id FROM sys.database_principals 
  WHERE name = N'foo';

SELECT r.name
FROM sys.database_principals AS r
INNER JOIN sys.database_role_members AS rm
ON r.principal_id = rm.role_principal_id
WHERE rm.member_principal_id = @pid;

SELECT p.state_desc, 
 p.[permission_name],
 [oschema] = QUOTENAME(s.name), 
 [object]  = QUOTENAME(o.name), 
 [column]  = QUOTENAME(c.name),
 tschema   = QUOTENAME(ts.name)
FROM sys.database_permissions AS p
LEFT OUTER JOIN sys.objects AS o
ON p.major_id = o.[object_id]
AND p.class_desc = N'OBJECT_OR_COLUMN'
LEFT OUTER JOIN sys.schemas AS s
ON o.[schema_id] = s.[schema_id]
LEFT OUTER JOIN sys.columns AS c
ON p.major_id = c.[object_id]
AND p.minor_id = c.column_id
LEFT OUTER JOIN sys.schemas AS ts
ON p.major_id = ts.[schema_id]
AND p.class_desc = N'SCHEMA'
WHERE grantee_principal_id = @pid;


So now to generate those scripts to apply to bar:

DECLARE @pid INT, @sql NVARCHAR(MAX) = N'', @trg SYSNAME = QUOTENAME(N'bar');

SELECT @pid = principal_id FROM sys.database_principals 
  WHERE name = N'foo';

SELECT @sql += CHAR(13) + CHAR(10) 
  + N'ALTER ROLE ' + QUOTENAME(r.name)
  + ' ADD MEMBER ' + @trg + ';'
FROM sys.database_principals AS r
INNER JOIN sys.database_role_members AS rm
ON r.principal_id = rm.role_principal_id
WHERE rm.member_principal_id = @pid;

SELECT @sql += CHAR(13) + CHAR(10) + N'' 
  + CASE p.state WHEN N'W' THEN N'GRANT' ELSE p.state_desc END
  + ' ' + p.[permission_name] + ' ON '
  + COALESCE(
    N'SCHEMA::' + QUOTENAME(ts.name),
    QUOTENAME(s.name) + '.' + QUOTENAME(o.name) 
      + COALESCE('.' + QUOTENAME(c.name), ''),
    N'DATABASE::' + QUOTENAME(DB_NAME())
  ) + ' TO ' + @trg + CASE p.[state] WHEN 'W' 
    THEN N'WITH GRANT OPTION' ELSE '' END + ';'
FROM sys.database_permissions AS p
LEFT OUTER JOIN sys.objects AS o
ON p.major_id = o.[object_id] AND p.class = 1
LEFT OUTER JOIN sys.schemas AS s
ON o.[schema_id] = s.[schema_id]
LEFT OUTER JOIN sys.columns AS c
ON p.major_id = c.[object_id]
AND p.minor_id = c.column_id
LEFT OUTER JOIN sys.schemas AS ts
ON p.major_id = ts.[schema_id] AND p.class = 3
WHERE p.grantee_principal_id = @pid
AND p.class IN (0,1,3); -- database, object/column, schema

PRINT @sql;
-- EXEC sp_executesql @sql;


Result will be something like this (now, PRINT has a limit of 8K, so you may not see the whole script in PRINT's output, but it's all there), but obviously not exactly:

ALTER ROLE [db_owner] ADD MEMBER [bar];
GRANT CONNECT ON DATABASE::[wp] TO [bar];
GRANT DELETE ON [dbo].[repro] TO [bar]; -- table
GRANT SELECT ON [dbo].[whatever].[a] TO [bar] WITH GRANT OPTION; -- column
DENY UPDATE ON [dbo].[whatever].[b] TO [bar]; -- column
DENY ALTER ON [dbo].[x] TO [bar]; -- procedure
GRANT EXECUTE ON [dbo].[x] TO [bar]; -- procedure
GRANT SELECT ON SCHEMA::[y] TO [bar];


Your goal is actually to apply the same permissions to a similar user in a different database, so you may need to adjust the target user (@trg) and replace DB_NAME() with the hard-coded name of the target database.

I am not sure if there are any cases where these permissions need to be applied in any sort of dependency order. I'm also not sure about other types of permissions that may interfere here (hence the WHERE clause - you can see the full set of class values in the documentation) - you may need permissions on things like TYPE, ROUTE, SERVICE_CONTRACT etc. You can expand the above script to cover those if necessary.