TRY changing @sql to

select @sql = 'bcp "select * from ORLANDO..vwEmpReport" queryout

c:\bcp\report.csv -c -t, -T -S'+ @@servername

try creating an alias in the local SQL Server that points to the actual machine name. Then use the alias as the server name of the linked server.

you could check the permission by using has_perm_by_name as posted

here

You could probably could look into sql server "functions" used as parameterized views.

At my place: http://www.nagios.org/ is King but "MOM" will probably replace it in the long run.

... I'm not getting the option in the GUI to view the reports

You must have SP2 on the CLIENT tool too

...

you are likely experiencing "blocking". Run a trace ( or sp_blocker script) to detect those and figure out what is the root cause

>>> So I did it manually by grant select on [schema]. to the user, but would this only give them access to that one object? <<

Yes ... as long as...

if the SQL Server logins already exists on the destination server you should use

sp_change_users_login 'Report' to verify which are orphaned

and sp_change_users_login 'UPDATE_ONE', 'user','user' to remap to

M$ has always been very careful not to maintain such thing. Sorry for the bad news.

CREATE TABLE xxxx(

Name varchar(20), Amount int

)

INSERT INTO xxxx (name, Amount) Values ('A', 15000)

INSERT INTO xxxx (name, Amount) Values ('A', 15000)

INSERT INTO xxxx (name, Amount) Values ('A', 15000)

INSERT INTO xxxx...

This is a very old problem in which politics are always involved. For "normal" day-to-day opearations you *don't* need admin rights. The problem ( in my experience ) comes when...

can you post DDL of your sample table.

The only thing needed is an after trigger which fires on inserts and updates.

for these situations I would use only scripts, not just UI.

A word of advice: if performance is important you may want to rethink this solution.