I think you are trying to use a table to store some kind of progressive number incremented by every call to some kind of procedure, am I wrong?

If so, UPDATE...

So try joining INSERTED, or you'll be updating the whole table. You can use the code I put in my previous post replacing [PrimaryKey] with the actual primary key of...

From BOL:

Backing Up to a File on a Network Share

For SQL Server to access a remote disk file, the SQL Server service account must have access to the network share....

I don't see references to the INSERTED table: try adding the join.

ALTER TRIGGER [dbo].[CC_TR_CANDIDATE_PF] ON [dbo].[CANDIDATE]

FOR UPDATE

AS

BEGIN

IF UPDATE(CUR_STAGE)

...

You can deny privileges to the users on the columns you don't want them to see:

DENY SELECT ON OBJECT::dbo.myTable(columntToHide) TO [LowPermissionUser]

Obviously they won't be able to issue statements like SELECT...

You could also achieve it by creating a table for the 3rd party software and adding a trigger instead of insert/update that populates your table.

Of course it would work for...

Ok, so do the contrary: use a table for 3rd party sw, and a view for your querying.

Use a view:

Example:

Table with your column names:

CREATE TABLE Orders (

ID int,

customerID char(100)

)

View with different column names:

CREATE VIEW LinkedOrders

AS

SELECT ID AS OrderNumber,

customerID AS...

You're not updating the results of you join statement, but you're updating one of the tables. Maybe your join statement doesn't match exactly one record from the first table with...

Personally I prefer looking at the query plan. Whenever I find a scan, I try to change it to a seek with the appropriate indexes. This depends on the arguments...

You're missing some commas between the parameters declaration.

CREATE PROCEDURE SearchFlightByCities

(

@startingFrom nchar(33) ,

@destination nchar(33) ,

@RowNum int )

...

Have you tried some kind of query refactoring to force the query optimizer to do what you expect?

Sometimes the same query with a different syntax takes a different query plan...

select...

I call database mail in a separate step as well, I find it being the simplest way.

If it works, don't touch it! 😉

I would never mess with index hints, let MSSQL choose the best plan for you.

Try updating statistics: poor query plans are often due to outdated statistics or bad indexes.

If your statements run fine taken one at a time, the problem is in the UNION. You have to ensure that the data type is the same for each column...