Gurus,
Is there a way to disable database logging while dropping
tables in SQL Server 6.5? In fact, is there a way to
disable logging completely? I realize this is no way to
run a production database, but sometimes extreme problems
call for extreme actions!
Will greatly appreciate any suggestions!
Thanks,
ChetChet
Turn the database option truncate log on checkpoint to on.
(In EM double click on the database you want and you will
find it under the options tab, just tick it)
Regards
John|||No you cannot completely turn off logging. You can set Trunc. log on Chkpt
and SELECT Into/Bulk Copy to true. What are your reasons for wanting to do
this "extreme problems"
--
--
Allan Mitchell (Microsoft SQL Server MVP)
MCSE,MCDBA
www.SQLDTS.com
I support PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org
"Chet" <chet.hodgins@.verizon.net> wrote in message
news:009801c351f3$71fcedd0$a101280a@.phx.gbl...
> Gurus,
> Is there a way to disable database logging while dropping
> tables in SQL Server 6.5? In fact, is there a way to
> disable logging completely? I realize this is no way to
> run a production database, but sometimes extreme problems
> call for extreme actions!
> Will greatly appreciate any suggestions!
> Thanks,
> Chet|||Thanks for the replies! This is a SAP development
database. We have 4 SAP tables that are have 2541, 2504
and 2543 errors. The data in these 4 tables are not
important. I have copied the tables to new customer
defined tables in SAP. Now want to drop the problem tables
and re-create them. Keep running out of log space (4GB)
before i can get to my first checkoint. Suggestions are
always appreciated!
Thanks,
Chet
>--Original Message--
>No you cannot completely turn off logging. You can set
Trunc. log on Chkpt
>and SELECT Into/Bulk Copy to true. What are your reasons
for wanting to do
>this "extreme problems"
>--
>--
>Allan Mitchell (Microsoft SQL Server MVP)
>MCSE,MCDBA
>www.SQLDTS.com
>I support PASS - the definitive, global community
>for SQL Server professionals - http://www.sqlpass.org
>
>"Chet" <chet.hodgins@.verizon.net> wrote in message
>news:009801c351f3$71fcedd0$a101280a@.phx.gbl...
>> Gurus,
>> Is there a way to disable database logging while
dropping
>> tables in SQL Server 6.5? In fact, is there a way to
>> disable logging completely? I realize this is no way to
>> run a production database, but sometimes extreme
problems
>> call for extreme actions!
>> Will greatly appreciate any suggestions!
>> Thanks,
>> Chet
>
>.
>
Showing posts with label logging. Show all posts
Showing posts with label logging. Show all posts
Friday, March 30, 2012
Monday, March 26, 2012
No Debugging and logging when a single script task is executed
Hi,
I cannot execute a script task in the VBA code window.
I cannot debug or log if I run a single script task from the right click Execute Task .
Every time I have to run the entire package in order to be able to debug.
What am I missing?
appreciate a help.
Gulden
try disabling all the other tasks and/or containers except the script task. then, execute the package.
|||Thank You.. I guess it is the only way..|||
Gulden wrote:
Thank You.. I guess it is the only way..
If memory serves correctly, yes, it IS the only way.
We hope this will change in the future. It certainly SHOULD be changed!
-Jamie
Monday, February 20, 2012
newbie: logging for stored procs
ok when debugging a stored proc, yes i can see print output etc in sql
query analyzer. but when the proc is called in production, i dont see that
output; moreover, im new and wondering what are the typical ways that you
all log stuff from a stored proc, etc.
is something like this common?
http://www.databasejournal.com/feat...cle.php/1467591jimbo-black wrote:
> ok when debugging a stored proc, yes i can see print output etc in sql
> query analyzer. but when the proc is called in production, i dont
> see that output; moreover, im new and wondering what are the typical
> ways that you all log stuff from a stored proc, etc.
> is something like this common?
> http://www.databasejournal.com/feat...cle.php/1467591
Presumably, you have PRINT statements in procedures while they are in
development for debugging purposes and those PRINT statements are
removed for production. If what you need is a parameter-driven method to
execute a procedure with logging, then you can use conditional
statements in the procedure to log to a table as the article explains
(or even issue PRINT statements for interactive testing). In general,
though, it's better to do this type of work in development and keep your
procedure code to a minimum. For batch routines that might need to log
their lengthly processes and progress, a logging table would be the way
to go.
David Gugick
Quest Software
www.imceda.com
www.quest.com
query analyzer. but when the proc is called in production, i dont see that
output; moreover, im new and wondering what are the typical ways that you
all log stuff from a stored proc, etc.
is something like this common?
http://www.databasejournal.com/feat...cle.php/1467591jimbo-black wrote:
> ok when debugging a stored proc, yes i can see print output etc in sql
> query analyzer. but when the proc is called in production, i dont
> see that output; moreover, im new and wondering what are the typical
> ways that you all log stuff from a stored proc, etc.
> is something like this common?
> http://www.databasejournal.com/feat...cle.php/1467591
Presumably, you have PRINT statements in procedures while they are in
development for debugging purposes and those PRINT statements are
removed for production. If what you need is a parameter-driven method to
execute a procedure with logging, then you can use conditional
statements in the procedure to log to a table as the article explains
(or even issue PRINT statements for interactive testing). In general,
though, it's better to do this type of work in development and keep your
procedure code to a minimum. For batch routines that might need to log
their lengthly processes and progress, a logging table would be the way
to go.
David Gugick
Quest Software
www.imceda.com
www.quest.com
newbie: logging for stored procs
ok when debugging a stored proc, yes i can see print output etc in sql
query analyzer. but when the proc is called in production, i dont see that
output; moreover, im new and wondering what are the typical ways that you
all log stuff from a stored proc, etc.
is something like this common?
http://www.databasejournal.com/features/mssql/article.php/1467591jimbo-black wrote:
> ok when debugging a stored proc, yes i can see print output etc in sql
> query analyzer. but when the proc is called in production, i dont
> see that output; moreover, im new and wondering what are the typical
> ways that you all log stuff from a stored proc, etc.
> is something like this common?
> http://www.databasejournal.com/features/mssql/article.php/1467591
Presumably, you have PRINT statements in procedures while they are in
development for debugging purposes and those PRINT statements are
removed for production. If what you need is a parameter-driven method to
execute a procedure with logging, then you can use conditional
statements in the procedure to log to a table as the article explains
(or even issue PRINT statements for interactive testing). In general,
though, it's better to do this type of work in development and keep your
procedure code to a minimum. For batch routines that might need to log
their lengthly processes and progress, a logging table would be the way
to go.
--
David Gugick
Quest Software
www.imceda.com
www.quest.com
query analyzer. but when the proc is called in production, i dont see that
output; moreover, im new and wondering what are the typical ways that you
all log stuff from a stored proc, etc.
is something like this common?
http://www.databasejournal.com/features/mssql/article.php/1467591jimbo-black wrote:
> ok when debugging a stored proc, yes i can see print output etc in sql
> query analyzer. but when the proc is called in production, i dont
> see that output; moreover, im new and wondering what are the typical
> ways that you all log stuff from a stored proc, etc.
> is something like this common?
> http://www.databasejournal.com/features/mssql/article.php/1467591
Presumably, you have PRINT statements in procedures while they are in
development for debugging purposes and those PRINT statements are
removed for production. If what you need is a parameter-driven method to
execute a procedure with logging, then you can use conditional
statements in the procedure to log to a table as the article explains
(or even issue PRINT statements for interactive testing). In general,
though, it's better to do this type of work in development and keep your
procedure code to a minimum. For batch routines that might need to log
their lengthly processes and progress, a logging table would be the way
to go.
--
David Gugick
Quest Software
www.imceda.com
www.quest.com
newbie: logging for stored procs
ok when debugging a stored proc, yes i can see print output etc in sql
query analyzer. but when the proc is called in production, i dont see that
output; moreover, im new and wondering what are the typical ways that you
all log stuff from a stored proc, etc.
is something like this common?
http://www.databasejournal.com/featu...le.php/1467591
jimbo-black wrote:
> ok when debugging a stored proc, yes i can see print output etc in sql
> query analyzer. but when the proc is called in production, i dont
> see that output; moreover, im new and wondering what are the typical
> ways that you all log stuff from a stored proc, etc.
> is something like this common?
> http://www.databasejournal.com/featu...le.php/1467591
Presumably, you have PRINT statements in procedures while they are in
development for debugging purposes and those PRINT statements are
removed for production. If what you need is a parameter-driven method to
execute a procedure with logging, then you can use conditional
statements in the procedure to log to a table as the article explains
(or even issue PRINT statements for interactive testing). In general,
though, it's better to do this type of work in development and keep your
procedure code to a minimum. For batch routines that might need to log
their lengthly processes and progress, a logging table would be the way
to go.
David Gugick
Quest Software
www.imceda.com
www.quest.com
query analyzer. but when the proc is called in production, i dont see that
output; moreover, im new and wondering what are the typical ways that you
all log stuff from a stored proc, etc.
is something like this common?
http://www.databasejournal.com/featu...le.php/1467591
jimbo-black wrote:
> ok when debugging a stored proc, yes i can see print output etc in sql
> query analyzer. but when the proc is called in production, i dont
> see that output; moreover, im new and wondering what are the typical
> ways that you all log stuff from a stored proc, etc.
> is something like this common?
> http://www.databasejournal.com/featu...le.php/1467591
Presumably, you have PRINT statements in procedures while they are in
development for debugging purposes and those PRINT statements are
removed for production. If what you need is a parameter-driven method to
execute a procedure with logging, then you can use conditional
statements in the procedure to log to a table as the article explains
(or even issue PRINT statements for interactive testing). In general,
though, it's better to do this type of work in development and keep your
procedure code to a minimum. For batch routines that might need to log
their lengthly processes and progress, a logging table would be the way
to go.
David Gugick
Quest Software
www.imceda.com
www.quest.com
Subscribe to:
Posts (Atom)