|
Hi,
I have a scheduled job set to run on server A, with 5 steps. One of the stored procs in this job, step 4 is taking a long time to complete, we moved it to another which does not take much time to execute. Now we are trying to change this step so it uses the other server B.
So on server A, I tried something like this -- exec serverB.database.dbo.sp_load_data.
This is not working. Is there a way to execute stored proc on another server?
Thanks!
|
|
|
|
|
It looks like you're using SQL Server so setting up a linked server on Server A should be all you need.
|
|
|
|
|
I am new to Linked servers.
If you have an article or some sort handy could you please post it.
Thanks so much for your time.
|
|
|
|
|
|
|
I see something set up for tables and view thru Linked servers.
I am using a stored proc. how would we do that?
|
|
|
|
|
Once the link is setup it can be called by
EXEC [linkedserver\instance].database.schema.sp I find it best to put [] around the linked part so I do not forget if I have a named instance (as shown).
|
|
|
|
|
I tried this.
Looks like RPC needs to be enabled on the remote server? is that the only way to go about?
|
|
|
|
|
I have a requirement that specifies that I need to block the access of a process to some records that are used by another process. This can be easily done by adding a Locked(bit) column and a ProcessID(int) column. The problem appears later in the specification when it says that in the case a process dies the rows locked have to be unlocked. The same must apply if the process is blocked in some way. Another problem is the fact that the login with which these processes run does not have VIEW SERVER STATE permission (nor it can be given that permission) so I can't use sysprocesses view or sp_who procedure.
Is there any way around this or another possible solution?
|
|
|
|
|
You fail to mention what db you are using.
If you use Oracle or DB2 you can Select for update...
There's a similar method for SQL server but it locks whole pages instead of records as far as I know.
"When did ignorance become a point of view" - Dilbert
|
|
|
|
|
I am sorry, I forgot to mention I use MSSQL Server.
|
|
|
|
|
Just another idea. Could you select the data and then delete it from the table. The data would then have to be persisted in memory or perhaps a different table. Once the process is complete and want's to make the data 'visible' again, it would then restore it to the original table. 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
Dear All,
1st, happy new year for all of you.
I have 2 tables, X and Z.
In real life, X contains one numerical field/coloumn that is the sum of 900 numerical inputs/records from table Z.
My question is, when designing the table X, should i include a feild/coloumn that contains the sum of the inputs/records in Y, or not, little bit confused 
Regards...
0 will always beats the 1.
|
|
|
|
|
scorp_scorp wrote: My question is, when designing the table X, should i include a feild/coloumn that contains the sum of the inputs/records in Y, or not, little bit confused
There's one option available of computed column in SQL Server, That's just giving you column value by applying formula you've provided while creating that column rather then storing physical data of SUM.
|
|
|
|
|
Thanks for the quick reply hiren, but, what i mean, is, if it is a good practice from a design point of view. Since some told me that i shoudnt, since i can get the sum in a report, query, or in a view, any time and then, i shouldnt save it in a table.
What do u think??
regards,
0 will always beats the 1.
|
|
|
|
|
Storing it physically though same data you can get that data anytime by querying isn't a good practice at all.
But What I mean is Computed column is invented for that purpose only it just computes value provided and gives you final answer in a column looks like it's physically storing data, but it isn't it's just a logical.
|
|
|
|
|
Hiren Solanki wrote: a column looks like it's physically storing data, but it isn't it's just a logical.
Got the point, thanks a lot, very helpfull.
Regards,
0 will always beats the 1.
|
|
|
|
|
Hiren Solanki wrote: Storing it physically though same data you can get that data anytime by querying isn't a good practice at all.
That isn't true - it depends on explicit and implicit business needs.
One consideration is volume and the load on the database. If summaries are common and significant in volume while being exactly the same summary (such as daily totals) then summing them once and then reserving that value can reduce load.
Another consideration is historical retention. It might not be possible or might be too complex to attempt to retain complex calculations which have inputs that vary over time. So the calculation is done at a point in time that is valid and then retained for later use to insure that reproducing reports (receipts or whatever) will still produce the same value.
|
|
|
|
|
As Hiren noted, a computed column would be a good solution. That would be re-evaluated every time you fetch the records, adding a performance-penalty. I'd go for a column in table X that would get updated with a trigger on table Z. That way the server only has to recount the new records once. The downside is that this would add more complexity than a computed column.
I are Troll 
|
|
|
|
|
A summary table is a good solution when the calculations are very complex or you delete/archive the data. Is that what you're doing?
|
|
|
|
|
scorp_scorp wrote: In real life, X contains one numerical field/coloumn that is the sum of 900 numerical inputs/records from table Z.
Does table Z have 900 rows or 900 billion?
Is table Z used in other queries that run once a day or 1000 times a second?
|
|
|
|
|
for each record in X, the amount of numerical feild correspond to sum of records "not more than 900 record" in Z. ie: table Z has more than 900 records (unlimited), but the sum in X is limited to a max number of 900 in Z.
Table Z is subjected to quireis, that accour not more than once a day.
Regards,
0 will always beats the 1.
|
|
|
|
|
hai,
i had wrote one storedprocedure for deleting the current leaves.but when i am debugging i am getting the error as invalid object name.i am posting the code.
USE [HDCHRMSDB]
GO
/****** Object: StoredProcedure [dbo].[apDeleteCurrentYearLeaveSummery] Script Date: 01/04/2011 12:23:41 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER Procedure [dbo].[apDeleteCurrentYearLeaveSummery]
As
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
DELETE FROM CurrentYearLeaveSummery Where Year=2011
END
please suggest any answer to avoid that error.urgent for me.
|
|
|
|
|
"Year" could be a reserved word.
If you have a column with that name, use [Year] instead.
Otherwise, it is a function, i.e. Year([My Column]).
|
|
|
|
|
First of all it's a Repost[^].
I think answer you've got of adding dbo.[name of table] may solve your problem.
Rather then posting code in different forum Discuss with people answered you over there.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
