Wednesday, March 21, 2012
Hi enterprise manager prob.
However, the Columns are backwards when I retrieve all rows, and when i go
to design a table.
Meaning to say that the ID starts on right side of screen, and scrollbar is
on left side (everything is backwards)
in options of enterprise manager, it says english is default language.
thanksThis sounds more like a Windows setting to me...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Michael" <Michael@.nospamplease.com> wrote in message
news:OEpXDJqCEHA.2592@.TK2MSFTNGP12.phx.gbl...
> Hi. I got Enterprise Manager to work finally.
> However, the Columns are backwards when I retrieve all rows, and when i go
> to design a table.
> Meaning to say that the ID starts on right side of screen, and scrollbar
is
> on left side (everything is backwards)
> in options of enterprise manager, it says english is default language.
> thanks
>
>|||Hi Tibor:
I had it working with enterprise manager 7.0. When I upgraded to 8.0 it's
like that. every other application on my machine is left to right -> only
that is right to left. Everything is English on my machine. Very weird.
Thanks.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:ertxVMqCEHA.1588@.tk2msftngp13.phx.gbl...
> This sounds more like a Windows setting to me...
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "Michael" <Michael@.nospamplease.com> wrote in message
> news:OEpXDJqCEHA.2592@.TK2MSFTNGP12.phx.gbl...
go
> is
>|||Got it to work - It was Windows Settings, thanks Tibor!!!
"Michael" <Michael@.nospamplease.com> wrote in message
news:OEpXDJqCEHA.2592@.TK2MSFTNGP12.phx.gbl...
> Hi. I got Enterprise Manager to work finally.
> However, the Columns are backwards when I retrieve all rows, and when i go
> to design a table.
> Meaning to say that the ID starts on right side of screen, and scrollbar
is
> on left side (everything is backwards)
> in options of enterprise manager, it says english is default language.
> thanks
>
>
Friday, February 24, 2012
Help: Prob handling SQL error in stored proc
I a stored procedure that inserts a record into a table as
below.
The insert works OK, but if the insert violates a unique
indewx constraint on one of the columns, the proc terminates
immediately, and does NOT execute the 'if @.@.ERROR <> 0'
statement.
Am I doing something wrong, or do I need to set an attribute
somewhere?
tia,
Bill
begin tran
insert into Users
(UserName, UserPWD, Lname, Fname, UserDesc)
values (@.userName, @.userPWD, @.lname, @.fname, @.userDesc)
if @.@.ERROR <> 0
begin
rollback tran
set @.returnCode = -2
set @.errMsg = 'SQL error '
+ convert(varchar(6), @.@.ERROR)
+ ' occurred adding user '
+ @.userName
end[posted and mailed, please reply in news]
Bill S. (bill_sheets@.hotmail.com) writes:
> I a stored procedure that inserts a record into a table as
> below.
> The insert works OK, but if the insert violates a unique
> indewx constraint on one of the columns, the proc terminates
> immediately, and does NOT execute the 'if @.@.ERROR <> 0'
> statement.
> Am I doing something wrong, or do I need to set an attribute
> somewhere?
>
> begin tran
> insert into Users
> (UserName, UserPWD, Lname, Fname, UserDesc)
> values (@.userName, @.userPWD, @.lname, @.fname, @.userDesc)
> if @.@.ERROR <> 0
> begin
> rollback tran
> set @.returnCode = -2
> set @.errMsg = 'SQL error '
> + convert(varchar(6), @.@.ERROR)
> + ' occurred adding user '
> + @.userName
> end
First, @.@.error is set after each statement, so @.errMsg will never read
anything but "SQL Error 0 ...". Always save @.@.error in a local variable
before you do anything else with it.
So over to your question. Error handling in SQL Server is a messy topic,
and there are errors you cannot trap like this, because SQL Server
aborts the batch immediately. However, constraint violation as you
mention is not among those - unless the setting SET XACT_ABORT is ON.
So, assuming you are not using XACT_ABORT ON, the error handler should
be executed. But how do you know that it is not? What are @.returnCode
and @.errMsg? Local variables? Output parameters? If they are output
parameters, and run the procedure from Query Analyzer:
DECLARE @.ret int, @.errMsg varchar(200)
EXEC your_sp @.userName, ..., @.ret OUTPUT, @.errMsg OUTPUT
SELECT @.ret, @.errMsg
My guess is that you are running the procedure from some client library
which traps the error, before you get to read the output parameters.
As I mentioned, error handling is really a messy topic, but I have
an article on error handling of my web site that may be of interest,
http://www.sommarskog.se/error-handling-II.html. I don't know exactly
on what level you are on; if you are fairly unexperienced with SQL
Server, you may feel overwhelmed, but you could browse it now, and
save it for later reading.
--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp