Change logfile location durring setup SQL 2000

Is there a possibility to change the default instalation directory for
the logfiles for sql server 2000? I would like the default database
files to be placed on teh d: drive and the logfiles on the e: drive?

Sjaak van Esdonksjaakvanesdonk@.hotmail.com (Sjaak van Esdonk) wrote in message news:<7479e65c.0311130551.56e84f0c@.posting.google.com>...
> Is there a possibility to change the default instalation directory for
> the logfiles for sql server 2000? I would like the default database
> files to be placed on teh d: drive and the logfiles on the e: drive?
> Sjaak van Esdonk

Setup doesn't have a separate path for the log files, however in
Enterprise Manager you can go into the Server Properties, and on the
Database Settings tab you can select a default location for new
database files. These values are saved in registry keys, so if you
need to do it programmatically, you can edit the registry directly:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\ MSSQLServer\DefaultData
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\ MSSQLServer\DefaultLog

Simon|||Thanks Simon, that seems to work !!

CATCH block question

Hello,
With the new TRY - CATCH block feature in 2005, is there any way for
the calling application to know about errors unless I use RAISERROR?
The reason I ask is, I'd like to start using the new TRY - CATCH
syntax, but I don't know if our code is set up to receive the specific
error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
In fact, I don't even know if our apps are set up to handle return
codes. I think the way things have generally worked is - the stored
procedure is just allowed to break, with no error handling at all.
DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
using RAISERROR, but still have the calling app know about it?
If not, that means we have to rewrite a lot of code, which is not
desireable.
Thanks
Hi
You could return a status value, but your client code should always cater
for RAISERROR and other scenarios where the procedure does not return a value.
John
"tootsuite@.gmail.com" wrote:

> Hello,
> With the new TRY - CATCH block feature in 2005, is there any way for
> the calling application to know about errors unless I use RAISERROR?
> The reason I ask is, I'd like to start using the new TRY - CATCH
> syntax, but I don't know if our code is set up to receive the specific
> error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
> In fact, I don't even know if our apps are set up to handle return
> codes. I think the way things have generally worked is - the stored
> procedure is just allowed to break, with no error handling at all.
> DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
> SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
> RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
> So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
> using RAISERROR, but still have the calling app know about it?
> If not, that means we have to rewrite a lot of code, which is not
> desireable.
> Thanks
>

CATCH block question

Hello,
With the new TRY - CATCH block feature in 2005, is there any way for
the calling application to know about errors unless I use RAISERROR?
The reason I ask is, I'd like to start using the new TRY - CATCH
syntax, but I don't know if our code is set up to receive the specific
error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
In fact, I don't even know if our apps are set up to handle return
codes. I think the way things have generally worked is - the stored
procedure is just allowed to break, with no error handling at all.
DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
using RAISERROR, but still have the calling app know about it?
If not, that means we have to rewrite a lot of code, which is not
desireable.
Thanks
You have to use RAISERROR to pass a logic error back to the application.
Of course, any unhandled errors, or critical SQL Server errors 'may' send an
error back to the application without having to raise an error.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
<tootsuite@.gmail.com> wrote in message
news:1160429120.981006.283160@.e3g2000cwe.googlegro ups.com...
> Hello,
> With the new TRY - CATCH block feature in 2005, is there any way for
> the calling application to know about errors unless I use RAISERROR?
> The reason I ask is, I'd like to start using the new TRY - CATCH
> syntax, but I don't know if our code is set up to receive the specific
> error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
> In fact, I don't even know if our apps are set up to handle return
> codes. I think the way things have generally worked is - the stored
> procedure is just allowed to break, with no error handling at all.
> DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
> SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
> RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
> So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
> using RAISERROR, but still have the calling app know about it?
> If not, that means we have to rewrite a lot of code, which is not
> desireable.
> Thanks
>
|||<tootsuite@.gmail.com> wrote in message
news:1160429120.981006.283160@.e3g2000cwe.googlegro ups.com...
> Hello,
> With the new TRY - CATCH block feature in 2005, is there any way for
> the calling application to know about errors unless I use RAISERROR?
> The reason I ask is, I'd like to start using the new TRY - CATCH
> syntax, but I don't know if our code is set up to receive the specific
> error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
> In fact, I don't even know if our apps are set up to handle return
> codes. I think the way things have generally worked is - the stored
> procedure is just allowed to break, with no error handling at all.
> DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
> SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
> RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
> So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
> using RAISERROR, but still have the calling app know about it?
>
No. Applications typically expect to receive an error message when
something goes wrong. For instance .NET clients will receive the error
message and raise a SqlException, thus invoking the client-side structured
exception handling. Conceptually this allows an error to propagate from
server code to client code.

> If not, that means we have to rewrite a lot of code, which is not
> desireable.
>
Probably not. For most clients, using RAISERROR to "re-raise" the error
"just works".
David

CATCH block question

Hello,
With the new TRY - CATCH block feature in 2005, is there any way for
the calling application to know about errors unless I use RAISERROR'
The reason I ask is, I'd like to start using the new TRY - CATCH
syntax, but I don't know if our code is set up to receive the specific
error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
In fact, I don't even know if our apps are set up to handle return
codes. I think the way things have generally worked is - the stored
procedure is just allowed to break, with no error handling at all.
DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
using RAISERROR, but still have the calling app know about it?
If not, that means we have to rewrite a lot of code, which is not
desireable.
ThanksYou have to use RAISERROR to pass a logic error back to the application.
Of course, any unhandled errors, or critical SQL Server errors 'may' send an
error back to the application without having to raise an error.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
<tootsuite@.gmail.com> wrote in message
news:1160429120.981006.283160@.e3g2000cwe.googlegroups.com...
> Hello,
> With the new TRY - CATCH block feature in 2005, is there any way for
> the calling application to know about errors unless I use RAISERROR'
> The reason I ask is, I'd like to start using the new TRY - CATCH
> syntax, but I don't know if our code is set up to receive the specific
> error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
> In fact, I don't even know if our apps are set up to handle return
> codes. I think the way things have generally worked is - the stored
> procedure is just allowed to break, with no error handling at all.
> DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
> SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
> RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
> So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
> using RAISERROR, but still have the calling app know about it?
> If not, that means we have to rewrite a lot of code, which is not
> desireable.
> Thanks
>|||<tootsuite@.gmail.com> wrote in message
news:1160429120.981006.283160@.e3g2000cwe.googlegroups.com...
> Hello,
> With the new TRY - CATCH block feature in 2005, is there any way for
> the calling application to know about errors unless I use RAISERROR'
> The reason I ask is, I'd like to start using the new TRY - CATCH
> syntax, but I don't know if our code is set up to receive the specific
> error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
> In fact, I don't even know if our apps are set up to handle return
> codes. I think the way things have generally worked is - the stored
> procedure is just allowed to break, with no error handling at all.
> DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
> SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
> RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
> So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
> using RAISERROR, but still have the calling app know about it?
>
No. Applications typically expect to receive an error message when
something goes wrong. For instance .NET clients will receive the error
message and raise a SqlException, thus invoking the client-side structured
exception handling. Conceptually this allows an error to propagate from
server code to client code.

> If not, that means we have to rewrite a lot of code, which is not
> desireable.
>
Probably not. For most clients, using RAISERROR to "re-raise" the error
"just works".
David

CATCH block question

Hello,
With the new TRY - CATCH block feature in 2005, is there any way for
the calling application to know about errors unless I use RAISERROR'
The reason I ask is, I'd like to start using the new TRY - CATCH
syntax, but I don't know if our code is set up to receive the specific
error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
In fact, I don't even know if our apps are set up to handle return
codes. I think the way things have generally worked is - the stored
procedure is just allowed to break, with no error handling at all.
DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
using RAISERROR, but still have the calling app know about it?
If not, that means we have to rewrite a lot of code, which is not
desireable.
ThanksHi
You could return a status value, but your client code should always cater
for RAISERROR and other scenarios where the procedure does not return a valu
e.
John
"tootsuite@.gmail.com" wrote:

> Hello,
> With the new TRY - CATCH block feature in 2005, is there any way for
> the calling application to know about errors unless I use RAISERROR'
> The reason I ask is, I'd like to start using the new TRY - CATCH
> syntax, but I don't know if our code is set up to receive the specific
> error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
> In fact, I don't even know if our apps are set up to handle return
> codes. I think the way things have generally worked is - the stored
> procedure is just allowed to break, with no error handling at all.
> DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
> SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
> RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
> So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
> using RAISERROR, but still have the calling app know about it?
> If not, that means we have to rewrite a lot of code, which is not
> desireable.
> Thanks
>