Can I ghost an SQL server?

I have a test environment that we rebuild servers on a regular basis.
To streamline the process we use ghost. We will be installing SQL on
the servers and want to build a ghost image with that build. We have
tested it by doing the build, loading the data, and then stopping all
the services and setting them to manual. After we Ghost the machine,
we start up the services and reset them to Automatic. Seems to work.

My question is:

Are there any risks? Should I expect any adverse affects?

Thanks for all your help!(otisim@.YAHOO.COM) writes:
> I have a test environment that we rebuild servers on a regular basis.
> To streamline the process we use ghost. We will be installing SQL on
> the servers and want to build a ghost image with that build. We have
> tested it by doing the build, loading the data, and then stopping all
> the services and setting them to manual. After we Ghost the machine,
> we start up the services and reset them to Automatic. Seems to work.
> My question is:
> Are there any risks? Should I expect any adverse affects?

Well, there is one catch. I assume that you rename the machines once
the ghosting as been completed. In this case @.@.servername is likely
to retain the old name or be NULL. In the latter case, you need to do:

sp_addserver NEWNAME, local

Restart SQL Server after this. If @.@.servername retains the old name
I would try dropping it with sp_dropserver first, although I don't
know if it works.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Actually, we are keeping the same name. This is because it is just a
rebuild of the same server.

In other words, we do some testing, we reimage the machine (so we start
with a fresh standard image), and then do more testing.

So we want to keep the same name. We are not using sysprep or making
any other changes. Same hardware, same build, same everything. Just
want to clear out any changes that were made during testing.

Thanks so much for the response.

Steve

Can I add a link in a users "My Reports" to a report on a different report server?

We are in the process of commissioning a new reporting server. In the interim, I want to be able to update/modify reports and publish to one location only, and publish links to the users "My Reports" on the old server. Any ideas folks?

Report Manager only talks to a single server, so you can't mix reports from one server with another.

A quick workaround would be to upload an HTML file as a resource into the user's My Reports folder which redirects them to the new server.

Can errors occur while committing a tx?

Can an error occur /during/ the process of committing a transaction?
BeginTraction();
try {
UpdateTable1();
UpdateTable2();
CommitTransaction(); <-- error here?
} catch(Exception e){
RollbackTransaction();
}
Also, what are the implications in such a situation where both the
Updates pass without any errors, but committing the transaction fails?
Is this scenario even possible at all?
If so, what are the suggested best-practices for recovering from such
types of errors?
TIA,
Abdullah"Abdullah Kauchali" <none@.none.com> wrote in message
news:eT1t1UAzFHA.1264@.tk2msftngp13.phx.gbl...
> Can an error occur /during/ the process of committing a transaction?
> BeginTraction();
> try {
> UpdateTable1();
> UpdateTable2();
> CommitTransaction(); <-- error here?
> } catch(Exception e){
> RollbackTransaction();
throw;
> }
>
Remember to rethrow the exception!
You know, that's a really good question.
Yes errors are possible, but pretty darn unlikely (at least in SQL Server).
When you go to commit the transaction all of the changes have allready been
made to the tables, and written to the memory cache of the log file. So
almost everything that could go wrong already would have. There could
possibly be some error flushing the log to disk, or you could loose your
connection to the database server, or the server could just fail. If the
commit fails on the server, the transaction will be rolled back (or at worst
it won't be there when the database recovers). But from a client there's
probably some possiblility that the commit succeeds, but a network problem
prevents you from learning about it.

> Also, what are the implications in such a situation where both the
> Updates pass without any errors, but committing the transaction fails?
The transaction will be rolled back.

> Is this scenario even possible at all?
> If so, what are the suggested best-practices for recovering from such
> types of errors?
>
Treat it like a server or network failure.
It's so unlikely to happen in the first place, and you are so unlikely to be
able to recover if it does, that I would just pretend like it's impossible.
Just pretend like it can't happen. Your responsibility is only to keep the
database in a logically consistent state. You've done that by coding your
transaction. You are not responsible for making sure the transaction
suceeds. That responsibility belongs to a higher context (ie a user or an
automated agent).
For most programs any kind of transaction retry is not worth the coding.
The code complexity and residual risk are just too great. Just propagate
the error out to the user or calling code and let them deal with it. You
just don't have the right context to deal with a server or network failures
in a meaningful way.
If you feel like you must deal with it, then propagate the exception out of
this method, and catch it at the level which knows how to retry the entire
transaction. Wait around for the instance to fail over to another server,
reconnect and issue the transaction again. If you know you are running
against a cluster with such high availability requirements that it the DBA's
must fail the instance over to perform routine maintenance then you can
expect this to happen, and you have no choice but to code around it. But in
any case the retry code does not belong in that method, but in an outer
controlling context.
David

Can errors occur while committing a tx?

Can an error occur /during/ the process of committing a transaction?
BeginTraction();
try {
UpdateTable1();
UpdateTable2();
CommitTransaction(); <-- error here?
} catch(Exception e){
RollbackTransaction();
}
Also, what are the implications in such a situation where both the
Updates pass without any errors, but committing the transaction fails?
Is this scenario even possible at all?
If so, what are the suggested best-practices for recovering from such
types of errors?
TIA,
Abdullah"Abdullah Kauchali" <none@.none.com> wrote in message
news:eT1t1UAzFHA.1264@.tk2msftngp13.phx.gbl...
> Can an error occur /during/ the process of committing a transaction?
> BeginTraction();
> try {
> UpdateTable1();
> UpdateTable2();
> CommitTransaction(); <-- error here?
> } catch(Exception e){
> RollbackTransaction();
throw;
> }
>
Remember to rethrow the exception!
You know, that's a really good question.
Yes errors are possible, but pretty darn unlikely (at least in SQL Server).
When you go to commit the transaction all of the changes have allready been
made to the tables, and written to the memory cache of the log file. So
almost everything that could go wrong already would have. There could
possibly be some error flushing the log to disk, or you could loose your
connection to the database server, or the server could just fail. If the
commit fails on the server, the transaction will be rolled back (or at worst
it won't be there when the database recovers). But from a client there's
probably some possiblility that the commit succeeds, but a network problem
prevents you from learning about it.
> Also, what are the implications in such a situation where both the
> Updates pass without any errors, but committing the transaction fails?
The transaction will be rolled back.
> Is this scenario even possible at all?
> If so, what are the suggested best-practices for recovering from such
> types of errors?
>
Treat it like a server or network failure.
It's so unlikely to happen in the first place, and you are so unlikely to be
able to recover if it does, that I would just pretend like it's impossible.
Just pretend like it can't happen. Your responsibility is only to keep the
database in a logically consistent state. You've done that by coding your
transaction. You are not responsible for making sure the transaction
suceeds. That responsibility belongs to a higher context (ie a user or an
automated agent).
For most programs any kind of transaction retry is not worth the coding.
The code complexity and residual risk are just too great. Just propagate
the error out to the user or calling code and let them deal with it. You
just don't have the right context to deal with a server or network failures
in a meaningful way.
If you feel like you must deal with it, then propagate the exception out of
this method, and catch it at the level which knows how to retry the entire
transaction. Wait around for the instance to fail over to another server,
reconnect and issue the transaction again. If you know you are running
against a cluster with such high availability requirements that it the DBA's
must fail the instance over to perform routine maintenance then you can
expect this to happen, and you have no choice but to code around it. But in
any case the retry code does not belong in that method, but in an outer
controlling context.
David

Can errors occur while committing a tx?

Can an error occur /during/ the process of committing a transaction?
BeginTraction();
try {
UpdateTable1();
UpdateTable2();
CommitTransaction(); <-- error here?
} catch(Exception e){
RollbackTransaction();
}
Also, what are the implications in such a situation where both the
Updates pass without any errors, but committing the transaction fails?
Is this scenario even possible at all?
If so, what are the suggested best-practices for recovering from such
types of errors?
TIA,
Abdullah
"Abdullah Kauchali" <none@.none.com> wrote in message
news:eT1t1UAzFHA.1264@.tk2msftngp13.phx.gbl...
> Can an error occur /during/ the process of committing a transaction?
> BeginTraction();
> try {
> UpdateTable1();
> UpdateTable2();
> CommitTransaction(); <-- error here?
> } catch(Exception e){
> RollbackTransaction();
throw;
> }
>
Remember to rethrow the exception!
You know, that's a really good question.
Yes errors are possible, but pretty darn unlikely (at least in SQL Server).
When you go to commit the transaction all of the changes have allready been
made to the tables, and written to the memory cache of the log file. So
almost everything that could go wrong already would have. There could
possibly be some error flushing the log to disk, or you could loose your
connection to the database server, or the server could just fail. If the
commit fails on the server, the transaction will be rolled back (or at worst
it won't be there when the database recovers). But from a client there's
probably some possiblility that the commit succeeds, but a network problem
prevents you from learning about it.

> Also, what are the implications in such a situation where both the
> Updates pass without any errors, but committing the transaction fails?
The transaction will be rolled back.

> Is this scenario even possible at all?
> If so, what are the suggested best-practices for recovering from such
> types of errors?
>
Treat it like a server or network failure.
It's so unlikely to happen in the first place, and you are so unlikely to be
able to recover if it does, that I would just pretend like it's impossible.
Just pretend like it can't happen. Your responsibility is only to keep the
database in a logically consistent state. You've done that by coding your
transaction. You are not responsible for making sure the transaction
suceeds. That responsibility belongs to a higher context (ie a user or an
automated agent).
For most programs any kind of transaction retry is not worth the coding.
The code complexity and residual risk are just too great. Just propagate
the error out to the user or calling code and let them deal with it. You
just don't have the right context to deal with a server or network failures
in a meaningful way.
If you feel like you must deal with it, then propagate the exception out of
this method, and catch it at the level which knows how to retry the entire
transaction. Wait around for the instance to fail over to another server,
reconnect and issue the transaction again. If you know you are running
against a cluster with such high availability requirements that it the DBA's
must fail the instance over to perform routine maintenance then you can
expect this to happen, and you have no choice but to code around it. But in
any case the retry code does not belong in that method, but in an outer
controlling context.
David

Can DTS read a file as one big blob?

(SQL Server 2000, SP3a)
Hello all!
I've got a pretty simple XML file that I'd like to process with DTS. I unde
rstand that
DTS doesn't have native capability for XML, so I was wondering if I could st
ill use DTS to
read in the entire source file and pass that into a stored procedure as a TE
XT argument?
Thanks for any help you can provide!
John PetersonHi John,
Not sure what you need to accomplish or what exactly process
the file means but with XML files, another option is to use
SQL Server 2000 Web Services Toolkit or just install SQLXML.
You can use the SQL XML Bulk Load object model to import XML
files. You could write this in an ActiveX script task in
DTS.
-Sue
On Sat, 13 Mar 2004 18:46:48 -0700, "John Peterson"
<j0hnp@.comcast.net> wrote:

>(SQL Server 2000, SP3a)
>Hello all!
>I've got a pretty simple XML file that I'd like to process with DTS. I und
erstand that
>DTS doesn't have native capability for XML, so I was wondering if I could s
till use DTS to
>read in the entire source file and pass that into a stored procedure as a T
EXT argument?
>Thanks for any help you can provide!
>John Peterson
>|||Thanks Sue!
Is the SQL XML Bulk Load object model part of the SQLXML package? I'm not w
holly familiar
with SQLXML -- my impression is that it's an add-on to SQL Server, and I kno
w the initial
reaction to our Hosting department will be to understand *why* it's necessar
y for us to
install that on the Production servers. But, if it's the right thing to do,
they'll
oblige.
I had thought to easily leverage some of the built-in XML features of SQL Se
rver, and I
think I could get DTS to invoke a SP that does some manipulation with OPENXM
L(), but I
wasn't sure how to get DTS to potentially squirt the contents of the XML fil
e into a NTEXT
parameter to the SP.
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:8idb50lj18hs2hopcvr11c5inrfs0gns2d@.
4ax.com...
> Hi John,
> Not sure what you need to accomplish or what exactly process
> the file means but with XML files, another option is to use
> SQL Server 2000 Web Services Toolkit or just install SQLXML.
> You can use the SQL XML Bulk Load object model to import XML
> files. You could write this in an ActiveX script task in
> DTS.
> -Sue
> On Sat, 13 Mar 2004 18:46:48 -0700, "John Peterson"
> <j0hnp@.comcast.net> wrote:
>
to
argument?
>|||Yup...the SQLXML bulk load object is part of SQLXML. It's
an add-on or additional component to install. I've used
SQLXML Bulk Load in ActiveX scripts to import XML files into
the relational tables.
The SQLXML OLEDB provider that comes with it also supports
inserting XML data - but I haven't messed with it and don't
know much about it other than it exposes the functionality
through ADO. There is also a managed provider to work with
.Net
The help files that come with it are pretty good and have
examples, samples that can be used to test out
functionality. You may want to download and install it on
your PC to see if it works for you. Excuse the long link and
watch out for line wrap:
http://www.microsoft.com/downloads/...&displaylang=en
-Sue
On Mon, 15 Mar 2004 08:53:49 -0700, "John Peterson"
<j0hnp@.comcast.net> wrote:

>Thanks Sue!
>Is the SQL XML Bulk Load object model part of the SQLXML package? I'm not
wholly familiar
>with SQLXML -- my impression is that it's an add-on to SQL Server, and I kn
ow the initial
>reaction to our Hosting department will be to understand *why* it's necessa
ry for us to
>install that on the Production servers. But, if it's the right thing to do
, they'll
>oblige.
>I had thought to easily leverage some of the built-in XML features of SQL S
erver, and I
>think I could get DTS to invoke a SP that does some manipulation with OPENX
ML(), but I
>wasn't sure how to get DTS to potentially squirt the contents of the XML fi
le into a NTEXT
>parameter to the SP.
>
>"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
> news:8idb50lj18hs2hopcvr11c5inrfs0gns2d@.
4ax.com...
>to
>argument?
>

Can default and named instance co-exist?

I have 2 Windows 2003 servers running SQL2000. They each have separate
databases. I am in the process of clustering these 2 machines together. I
have purchased a shared external SCSI PowerVault appliance to put the quorom
and the shared databases on. I want to create a Virtual SQL server using
these 2 machines and put their separate databases on the virtual server. My
question is:
Do I have to uninstall SQL server on each machine before I install the
virtual server? If I have to I would have to restore my databases to the new
virtual server
Or can I just install a new named instance of SQL server - choosing the
virtual server in the setup? If I can do this - it would be a lot easier
moving my databases over to the new server.
If I can just create a new virtual server with leaving the original SQL in
tact - will the original still be available to my users if I decide not to
move all the databases over that day?
Is there one way that is better than the other?
1. If you want to use the exact same instance names, uninstall/reinstall for
clustering is needed. If not, you can just virtualize your new instance and
migrate data.
2. Consider reading through this kb for some details
http://support.microsoft.com/kb/224071
3. Your original instance will continue to run while you're installing a new
instance on the same node.
The bottom line, I would create a new instance and ensure it's up and
running before tinkering with the original.
-oj
"Amy Lewis" <AmyLewis@.discussions.microsoft.com> wrote in message
news:223F3934-2F36-4A2D-B5D5-D860055AE5E7@.microsoft.com...
>I have 2 Windows 2003 servers running SQL2000. They each have separate
> databases. I am in the process of clustering these 2 machines together.
> I
> have purchased a shared external SCSI PowerVault appliance to put the
> quorom
> and the shared databases on. I want to create a Virtual SQL server using
> these 2 machines and put their separate databases on the virtual server.
> My
> question is:
> Do I have to uninstall SQL server on each machine before I install the
> virtual server? If I have to I would have to restore my databases to the
> new
> virtual server
> Or can I just install a new named instance of SQL server - choosing the
> virtual server in the setup? If I can do this - it would be a lot easier
> moving my databases over to the new server.
> If I can just create a new virtual server with leaving the original SQL in
> tact - will the original still be available to my users if I decide not to
> move all the databases over that day?
> Is there one way that is better than the other?
|||Each instance of SQL Server requires its own shared disk. You can install
either 1 default instance and 15 named instances or up to 16 named
instances, but each must have its own shared drive. All drives must have a
drive letter, no mount points allowed. For existing nonclustered instances,
if you move the data files to a shared drive then you will have the option
during setup to upgrade the standalone instance to a virtual/clustered
instance (assuming you're using the Enterprise Edition setup).
Cindy Gross, MCDBA, MCSE
http://cindygross.tripod.com
This posting is provided "AS IS" with no warranties, and confers no rights.

Can data be queried in OLAP cubes as in Views?

This question may appear a bit pedestrian but nonetheless.

We are in the process of building OLAP cubes for data analysis purposes. The question that we have is simply can we access the data stored in the OLAP cube in the same way that we would a View. We utilise a simple VB reporting tool that allows us to dynamically interrogate views in our SQL databases. Would this functionality apply also to OLAP.

Regards

RepomanYou can build a cube off of a single table or from a view.

HTH|||I didn't try it yet, but I know that SQL Server has a different OLE DB provider for it's analytical services. You will need to use it to connect to your cube.|||After further research it appears that we cannot just plug directly in. I think we need to use MDX to call the Cube. The resultant data can then be passed to our report builder.

Many thanks for the answers nonetheless.

Regards

Repoman|||Guess I'm not clear on what you are asking. If you build your cubes with ROLAP (relational - OLAP) the cube will build/store your cube in a relational matter. MDX you can use to build calculated members on a cube, what is it you are trying to do?

Can a stored procedure parameter be optional

I want the procedure to check for the existence of a paramter and if it is
there, it will process these instructions, otherwise it will process these
instructions. Any ideas? Thanks for your advice.

Regards,
CKoptional parameters have to be at the end of a stored proc
CREATE PROCEDURE get_sales_for_title
@.something int,
@.title varchar(80) = NULL

AS

-- Validate the @.title parameter.
IF @.title IS NULL
BEGIN
print 'do something here'
END
ELSE
BEGIN
print 'do something else here'
END

now you can call this proc like this
exec get_sales_for_title 1
or like this
exec get_sales_for_title 1,2
you will see that the print statement will be different for the 2 calls

http://sqlservercode.blogspot.com/|||Try:

create proc MyProc
(
@.parm1 int -- mandatory
, @.parm2 int = 5 -- optional
)
as
...

--
Tom

----------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com

"CK" <c_kettenbach@.hotmail.com> wrote in message
news:sBlPf.43261$F_3.25017@.newssvr29.news.prodigy. net...
I want the procedure to check for the existence of a paramter and if it is
there, it will process these instructions, otherwise it will process these
instructions. Any ideas? Thanks for your advice.

Regards,
CK|||CK (c_kettenbach@.hotmail.com) writes:
> I want the procedure to check for the existence of a paramter and if it is
> there, it will process these instructions, otherwise it will process these
> instructions. Any ideas? Thanks for your advice.

Yes, consider:

CREATE PROCEDURE some_sp @.a int,
@.b int = 465 AS
PRINT @.a + @.b
go
EXEC some_sp 1

Prints 466. You can even say:

EXEC some_sp 1, DEFAULT

to explicitly say that you want the default value to be used.

The most commonly used default value for stored procedure parameters is
probably NULL.

Note that there is no way in the stored procedure to tell whether
the parameter was actually specified in the call, or whether the
default was used. That is, inside some_sp you cannot tell the
difference between

EXEC some_sp 1

and

EXEC some_sp 1, 465

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Yes, as you have seen, but you might want to review your old Software
Engineering notes about coupling and cohesion in code modules.|||>es, as you have seen, but you might want to review your old Software
Engineering notes about coupling and cohesion in code modules.

in your world on a cloudless day, what color is the sky???|||SQL (denis.gobo@.gmail.com) writes:
> optional parameters have to be at the end of a stored proc
> CREATE PROCEDURE get_sales_for_title
> @.something int,
> @.title varchar(80) = NULL
> AS

No, there is now such law. While it may be practical to have parameters
with default value at the end, this is perfectly legal:

CREATE PROCEDURE some_sp @.x int = NULL, @.u INT AS
...
go
EXEC some_sp @.u = 123

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||True,
I should have been more specific and should have said that you have to
put them at the end if you want to call the proc with the parameters by
position instead of by name

CREATE PROCEDURE some_sp @.x int = NULL, @.u INT AS
select getdate()
go
EXEC some_sp @.u = 123 --fine

EXEC some_sp 123 --will fail

http://sqlservercode.blogspot.com/

Can a commit fail??

Can an error occur /during/ the process of committing a transaction? So:
BeginTraction();
try {
UpdateTable1();
UpdateTable2();
CommitTransaction(); <-- error here?
} catch(Exception e){
RollbackTransaction();
}
Also, what are the implications in such a situation where both the
Updates pass without any errors, but committing the transaction fails?
Is this scenario even possible at all?
If so, what are the suggested best-practices for recovering from such
types of errors?
TIA,
AbdullahYes. If the log disk fills up, the write of the commit sentinal can fail,
thus it's indeed possible for a commit to fail. I'm sure that there are
other scenarios that could cause a commit failure. Therefore, if the commit
fails, the transaction should be rolled back (if that hasn't already
happened as a result of the failure).
"Abdullah Kauchali" <none@.none.com> wrote in message
news:ukGjDWAzFHA.1264@.tk2msftngp13.phx.gbl...
> Can an error occur /during/ the process of committing a transaction? So:
> BeginTraction();
> try {
> UpdateTable1();
> UpdateTable2();
> CommitTransaction(); <-- error here?
> } catch(Exception e){
> RollbackTransaction();
> }
> Also, what are the implications in such a situation where both the
> Updates pass without any errors, but committing the transaction fails?
> Is this scenario even possible at all?
> If so, what are the suggested best-practices for recovering from such
> types of errors?
> TIA,
> Abdullah|||Brian Selzer wrote:
> Yes. If the log disk fills up, the write of the commit sentinal can fail,
> thus it's indeed possible for a commit to fail. I'm sure that there are
> other scenarios that could cause a commit failure. Therefore, if the comm
it
> fails, the transaction should be rolled back (if that hasn't already
> happened as a result of the failure).
Thanks Brian.
Let's use your example. Suppose UpdateTable1() succeeds during the
COMMIT (SQL Server frees the resources and releases the locks for
Table1) and then attempts to commit statements in UpdateTable2() but
then realises "oops, transaction log is full!" Will UpdateTable1()
rollback on a rollback instruction? Won't the transaction logs still
be considered full for the rollback log entries to go through?
:)
(I am actually trying to understand the process of commit in a 2-phase
scenario (distributed transactions), but I'd like to understand the
concept from a local-transaction point of view first. So, I apologise
for my lack of knowledge there!
My question for the 2-phase (distributed) transaction is this: if the
DTC commits all preceding resources and then encounters a problem with
the very last resource in the chain of updates, can/does the DTC
actually "uncommit" the preceding resources it just instructed to
commit? No during the prepare phase, but during the commit phase.)|||The commit of UpdateTable1() succeeded, so a rollback isn't possible. The
commit of UpdateTable2() fails, the log file is full, and the database shuts
down. During recovery (assuming disk space has been freed or otherwise made
available), UpdateTable2() will be rolled back. Changes are written to the
transaction log before they're written to the database, and only after all
of the database changes have been flushed to the disk is the commit sentinal
written to the transaction log, so the recovery process can undo any changes
made by any uncommitted transactions.
I'm not sure exactly how the process works with a distributed transaction.
Maybe there's a different type of sentinal written to the transaction log
after the prepare phase has completed. During the prepare phase, all cached
changes in each participant are flushed to the disk and then a
ready-to-commit signal is sent back to the coordinator. Once the commit
signal has been sent, I don't think a rollback is possible, even if an error
occurs on one of the other participants. If communication is lost before
the commit signal is received, then the participant is required to roll back
the transaction. If it happens afterward, the transaction is supposed to be
committed. Again, I'm not sure exactly how the process works under the
covers. Maybe someone with more knowledge than I can give you a more
difinitive answer.
"Abdullah Kauchali" <none@.none.com> wrote in message
news:uUupV7EzFHA.1856@.TK2MSFTNGP12.phx.gbl...
> Brian Selzer wrote:
> Thanks Brian.
> Let's use your example. Suppose UpdateTable1() succeeds during the
> COMMIT (SQL Server frees the resources and releases the locks for
> Table1) and then attempts to commit statements in UpdateTable2() but
> then realises "oops, transaction log is full!" Will UpdateTable1()
> rollback on a rollback instruction? Won't the transaction logs still
> be considered full for the rollback log entries to go through?
> :)
> (I am actually trying to understand the process of commit in a 2-phase
> scenario (distributed transactions), but I'd like to understand the
> concept from a local-transaction point of view first. So, I apologise
> for my lack of knowledge there!
> My question for the 2-phase (distributed) transaction is this: if the
> DTC commits all preceding resources and then encounters a problem with
> the very last resource in the chain of updates, can/does the DTC
> actually "uncommit" the preceding resources it just instructed to
> commit? No during the prepare phase, but during the commit phase.)
>