May 4, 2011 at 1:28 pm
Let me start by asking a few questions
Does the table V_KASSTRNS exist in the FUTURA_CHINA database on the APP06 server?
It is prefaced with a V, does that mean it is a view?
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
May 4, 2011 at 2:13 pm
I'm guessing toward the same direction as Stefan:
Assuming V_KASSTRNS and V_PERSONAL are views, both could have the hardcoded APP06 linked server referenced in the underlying query.
I'd check the definition of those views(?).
To find the one causing the issue, run
SELECT TOP 1 FROM V_KASSTRNS
and
SELECT TOP 1 FROM V_PERSONAL
and check which one fails.
May 4, 2011 at 4:35 pm
Hi
Yes they are in futura_China database.
May 4, 2011 at 4:48 pm
Does the sproc return any error when run from SSMS (Management Studio)?
If so, what tool do you use to "run (and design) the report in intranet"? Assuming it is SSRS (Reporting Services) there might be an issue with the connection string in the report itself pointing to a wrong data source.
Or it is "just" what the error message tells: the user has no permission to run this report. If possible, try to run the sproc from the SSRS in design mode using the same login as used on the intranet.
May 4, 2011 at 5:31 pm
kcheluvaraj 94771 (5/4/2011)
HiYes they are in futura_China database.
Are they views? If they're views it is possible that they are still pointing at tables on the old server. Look at the design and see what the structure is. Also, try to open the views directly and see what happens.
Is the stored procedure that you're running running on the APP06 server? Is it running in the futura_China database?
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
May 4, 2011 at 6:12 pm
The next thing I'd try is to run it with a user mapped as database owner on futura_china. If that works, then the error is somewhere in your user permissions. If it still doesn't work, we'll have to keep looking elsewhere. If it does work, you can remove levels of permission until it stops working again and you'll know what level you need.
The problem I'm having here is why you're getting this error. You're not referencing APP06 from this stored procedure. You're running this on APP06, right? Have you tried changing it from a stored procedure to a regular query and running it that way?
You've run the ALTER PROCEDURE to make sure it has the APP06 lines commented out, right?
Sorry to be running over the simple things, but that's what I'd be checking if it werre on my machines.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
Viewing 6 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply