|
[x]
The Solution Rating System
|
|
|
With so many solutions, how can you tell which solutions are most likely to help you and which ones are not? To provide you with a tool to use, we rate our solutions based on various elements that most accurately determine if a solution is a quality solution. To explain what factors affect the solution rating, here are the elements we take into consideration when formulating our solution rating. - The Grade of the Solution
- The Zone Rank of the Expert Providing the Solution
- The Number of Author and Expert Comments
- The Number of Experts Contributing
- The Feedback of the Community
Your Input Matters
Because of the way the system is set up, the most important variable in this equation is you. As a member of Experts Exchange, you are able to cast your vote on the quality of the solutions in regard to how complete, accurate, helpful and easy to understand each solution is. When you provide your feedback, each rating is adjusted accordingly. So, if you see a solution that has a poor rating that you think is a good solution, let us know by rating it. As you do, the rating will be adjusted and will become more accurate for other members of our site. If you have any suggestions that you would like to make for our rating system, please ask a question in the Suggestions Zone of Community Support. Thank you! |
|
|
|
|
i have this great big ugly procedure for insertion --
if @time is today or less, insert into current table
if @time within the last 7 days, insert into both current table & historical table
if @time is older than 7 days, insert only historical table
to date, all that works fine. i have to change it, though, to account for a new development
user will see an order, and transfer this order to another user, purely by running the insert with the given parms into a new userid.
immediatlely thereafter (behind the scenes), i need to insert another order to the original userid, making them flat.
see this example - userA has a BUY order of 5 on AAPL
-- i need to insert a BUY order of 5 on AAPL to userB
-- insert a SELL order of 5 on APPL to userA
thus, the order has been transferred to userB and userA is flat
like i said, that 2nd insert needs to happen behind the scenes. all user is doing is running the insert that will transfer/insert the order in question to the given @userID
i thought maybe i could coalesce on @userid, @newuserid, but i'm not sure how best to control that flow
here's the 1st chunk of the proc which writes only to the current day table.
would anybody be able to advise as to whether this is the correct way to flow thru this?
BEGIN TRANSACTION
IF DATEDIFF(day,@time,getdate())<=0
/* if date is current day, insert only into dbo.table */
BEGIN
IF(@newuserID IS NOT NULL)
BEGIN
INSERT dbo.table (
[userId],[acctId],[PrevOrderNo],[endpoint],[Symbol],[side],[Quantity],[Price],[Time],[OrderNumber] )
VALUES (@newuserId,@newacctId,@PrevOrderNo,@endpoint,@Symbol,@side,@Quantity,@Price,@Time,@OrderNumber )
END
ELSE
BEGIN
INSERT dbo.table (
[userId],[acctId],[PrevOrderNo],[endpoint],[Symbol],[side],[Quantity],[Price],[Time],[OrderNumber] )
VALUES (
@userId,@acctId,@PrevOrderNo,@endpoint,@Symbol,@side,@Quantity,@Price,@Time,@OrderNumber )
IF @@ERROR <> 0
BEGIN
ROLLBACK TRAN
RAISERROR('Failed to insert into dbo.table.',16,-1)
RETURN
END
END
and my error handling, is that ok?
very, very important. please advise.
