|
One version is:
UPDATE TableName
SET ColB = CASE
WHEN ColA < 0 THEN 0
ELSE ColA
END;
Correction based on the good feedback by musefan:
UPDATE TableName
SET ColB = CASE
WHEN ColA >= 0 THEN 0
ELSE ColA
END
The need to optimize rises from a bad design.My articles[^]
modified on Wednesday, March 23, 2011 12:16 PM
|
|
|
|
|
I think you misread the requirement (even thou you got an accepted answer), ColB should be 0 for NON-negative numbers
I may or may not be responsible for my own actions
|
|
|
|
|
You're right for non-negative it's vice versa. I think the OP still got the idea. 
|
|
|
|
|
UPDATE table SET colB = DECODE( SIGN( colA ), -1, colA, 0 )
|
|
|
|
|
Reading excel file with OPENROWSET of sql server.
Working fine and getting values.
Now, if the file which i am reading is in use (opened), it gives error.
How should i capture this error, I tried
Declare @error varchar(50)
SELECT *
FROM OPENROWSET('Microsoft.Jet.OLEDB.4.0',
'Excel 8.0;Database=\\webex\cis\CIS overview.xls',
'SELECT * FROM [CIS Overview$]')
IF(@@error <> 0 )
BEGIN
Set @error = 'Error reading file'
RETURN
END
But its not even reaching to IF clause,
terminate giving message
OLE DB error trace [OLE/DB Provider 'Microsoft.Jet.OLEDB.4.0' IDBInitialize::Initialize returned 0x80004005: The provider did not give any information about the error.].
Msg 7399, Level 16, State 1, Line 3
OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error. The provider did not give any information about the error.
How can i capture this error ?
reagards
|
|
|
|
|
|
Any other Light ?
As i am using sql 2000 
|
|
|
|
|
Okay, and you're sure the IF is not hit at all... One thing you could try is to call this procedure from another and check if you can handle the error properly in the calling procedure.
|
|
|
|
|
Mika Wendelius wrote: you're sure the IF is not hit at all...
Well instead of if you can use PRINT, if control reaches to print it should print.
But execution terminates on OPENROWSET itself.
Mika Wendelius wrote: call this procedure from another and check if you can handle the error properly in the calling procedure.
No luck !
in a new query window i tried like
EXEC [spName]
IF(@@error <> 0)
BEGIN
Print 'No error'
END
ELSE
BEGIN
Print 'error'
END
here also not going to if clause !
Any other suggestion?
|
|
|
|
|
Hmm, what happens if you try to execute the statement dynamically. Put it into a string and then use exec to run the statement. Unfortunately I don't have SQL Server 2000 to test this issue...
|
|
|
|
|
Hi,
I am trying to implement a dialog for updating some data in a DB. The OK button should actually save the data to the DB, while the Cancel button should discard the changes. The problem is, I need to be able to read the changed but not yet committed data within the dialog. I have read much information about transactions, isolation levels etc. and if I understand it correctly, the only way to achieve this is to wrap all the changes in a single transaction and use the READUNCOMMITED isolation level for it. Then in the OK button handler I'd just commit the transaction and in the Cancel button handler I'd call rollback.
However, since I am using the SQLite.NET library, I am only able to use READCOMMITTED or SERIALIZABLE levels. What's more, in some other piece of software I have which uses MS Access database and solves exactly the same problem the transaction is started with the READCOMMITED isolation level and everything works as intended. That really puzzles me. 
Do you have any suggestions/advice for this kind of problem?
|
|
|
|
|
Perhaps I misunderstand your question, but the whole idea of using a dialog is to let the user determine the variables.
Once this is done, it's easy enough to validate the input in your code, before even creating a query.
My advice is free, and you may get what you paid for.
|
|
|
|
|
The dialog doesn't just show some variables. It lists (complex) objects from the database and should allow adding/deleting/editing them. When he adds a new object he might decide to edit it before leaving the dialog, so I need to be able to store its properties somewhere. Of course I could hold the references to the new objects in my code, but I thought the most elegant way would be to store them in the DB immediately and access them in a unified way. Of course I still need the option to roll back all the changes when the user hits Cancel.
|
|
|
|
|
Well, the basic choice is to keep all the data in client memory, or server memory, or write the whole thing to disk, right?
If you have lots of clients sending transactions to a database server at the same time, I'd try and do all the work on the client.
If the user might use a lot of time performing a transaction, a simple and robust solution could be to store the whole transaction in a temporary table (or structure of tables). That way you can perform some of the validation directly on input in your app, and then when the user clicks ok, you can still run some validation first between transactions from different users, and then commit the transaction to the live tables after that. If the user clicks cancel just delete the object from the temporary table.
An added advantage of this method, is that you can think about offering the user "template" or "favorite" transactions.
My advice is free, and you may get what you paid for.
|
|
|
|
|
Sure, it's always an option (albeit a cumbersome one) to store all the changes in the client code until the user hits OK or Cancel. I just wanted to know whether it is possible to set a "restore point" and later roll back all the changes up to that point. The database is single-user, so there won't be any read/write conflicts.
|
|
|
|
|
The first rule of transactions is: Never have a conversation with the user while a transaction is active!
So what you should do is to ask all the necessary questions before you start the db operations, perhaps show what's in the database now and how it's going to be changed etc. After the last yes/no question, then do all the operations at once and if everything goes fine, commit otherwise rollback.
In my opinion (I know many disagree) Read uncommitted should be banned for good. In a well designed system there's no need for RU isolation level and as you mentioned many of the database products don't even support it (inlcude Oracle in your list).
Having UI conversations etc while you have placed locks in the database typically causes prolonged transactions, slows the system down and decreases parallelism because of locking issues.
|
|
|
|
|
I am not sure if I am phrasing the question right, which is probably also why I haven't been able to find an answer anywhere.
The situation is as follows: I have an ERP system using an MS SQL 2005 database.
There are several tables in the database that contain document data (i.e. orders, deliveries, invoices, etc). These tables get a lot of read and write action under normal use of the ERP system.
There are several heavy ad hoc queries saved in the system, and also some user applications and timed console apps that run heavy queries (sales reports, purchase forecasts, and such).
The result is that in daily use such a strain is placed on the document tables that we get constant timeouts, and/or applications (and the ERP system itself) grinding to a halt when too many users / applications are using the system at the same time.
The question is: Considering that I can hardly or not at all touch database settings, and I certainly can not fool around with the table structures themselves, I am thinking of making our applications and ad hoc queries not perform read operations directly on the tables in question. Also most of the data should be up to date to within say an hour.
What are my options ? Would using views or a synchronized db help ? Any other solution ?
Cheers,
Johan
My advice is free, and you may get what you paid for.
|
|
|
|
|
One option is to publish a copy of the tables to a second database for reporting. See Replication in BOL.
Also tuning of the queries might help. If the reports are a job move the time slightly.
Good luck,
djj
|
|
|
|
|
Thanks for the tip ! I looked into publishing a little, and it definitely looks promising.
Cheers,
Johan
My advice is free, and you may get what you paid for.
|
|
|
|
|
Sorry I could not give more info but I have only played around with publish replication (no actual usage). We do log shipping which also could work but I think the publish would be better for you.
|
|
|
|
|
Don't worry about it, I don't mind doing the research. That nudge in the right direction was really all I needed.
My advice is free, and you may get what you paid for.
|
|
|
|
|
There are a huge number of things you can do to tune the performance on a database. It sounds like you have a major corporate database and no real skills (DBA level) to service the thing. I STRONGLY suggest hiring a consultant (finding a good one can be a challenge) to look at the infrastructure.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I think you got the wrong end of the stick. Admittedly, I don't have the skills of a dedicated database administrator, but I am not completely useless with MS SQL. Our company is just a small (50 people) outfit, our ERP system is a small SAP product (Hence, no touching db settings and such), and the database (settings, structure, etc) in question is designed by SAP and specifically dedicated to the ERP system.
Engaging a consultant, we did in a sense, by having SAP support taking a look at it, but they could find nothing wrong, and only suggested some basic maintenance tasks (which we already use).
The problem appears to be that normal daily use, ad hoc queries, and all the automation we have built around the system strain the database beyond its original design. This is why I am looking into lessening the strain, instead of tuning the db.
My advice is free, and you may get what you paid for.
|
|
|
|
|
If you are joining together a lot of tables and then make an aggregation on that join in one big query, you'll take a serious performance hit.
Have a look if it's possible to do the aggregation separately and then make the joins.
As similar to this:
WITH SalAgg as (
SELECT SUM(sal) sal
,DeptID
From Emp
)
Select deptid
,sal
,More info
,even more info
from SalAgg s
join Dept d
On s.deptid = d.deptidIf you dont like CTE[^]s you can of course use inline views instead.
Do also take a look at Indexed views[^].
|
|
|
|
|
I use both normal joins and inline views, but I didn't know that using aggregation with straightforward joins performs different from inline views. Also I have never seen this WITH structure you used in your example. Thanks very much for that. I am going to check a lot of our apps and queries now, to see if I can streamline them this way.
My advice is free, and you may get what you paid for.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
