Is transaction name has to be unique?

Hi

I remember that once I had a problem when using a cursor in a sp and when several instances of the sp were running I had a problem when the first sp in the sequence deallocated the cursor and all the other who run in parallel had errors...
Well, this is not the problem now, but my question is, if I have a sp that has begin tran t1, and several instances of the sp are running in parallel, and each of course has begin tran t1, should I expect the same collision effect like with the cursor? Is every tran has to be with unique name? Or maybe the server knows how to manage this and when one tran has started and another sp tried to start another with the same name it makes it wait until the first one committed or rolled back?

Thanks,
Inon.I would think that this would be a particularly bad idea, though I have no specific experience in this area (transaction numbers). As I always understood it, the idea behind an explicitly identified transaction was to be able to roll back that specific transaction, particularly in an asynchronous environment. You have to ask yourself, what is the value in re-using the same transaction identifier? If you are just going to re-use the same identifier, then why bother with an identifier at all?

Regards,

hmscott

Is there any advantage for creating a default instance vs. a named

Hello, DBA outthere.
I understand that SQL Server 2000 allows 1 default instance and up to 15
named instances per server. I believe the default instance needs to be
created first.
Is there any reason to have more than 1 instance per server? Does having
more than one instance affect the overall SQL server performance? SQL
2000 server also allows server alias if users to have different server
naming.
I usually create named instance for new installation instead of letting
the SQL setup create the default instance. I had some run-ins with using
named instance. Some not-so-well-prepared application setups looks into
the registry for default instance
(HKL\Software\Microsoft\MSSQLServer\MSSQLServer). If whatever they looks
for is not there, the application will fail. Developers need to take
into account that as SQL Server allows DBA to create either default or
named instance or both.
In any event, give share your thoughts on using default or named instance.
Thanks.
JJ.Hi
Having multiple instances will stretch your resources more. You may want to
create multiple instances if you have a packaged application that require
specific settings or maybe because of issues of security.
I don't think you have to create the default instance first although I have
never tried doing otherwise!
John
"John Joe" <yukondba@.hotmail-lessspam.com> wrote in message
news:%234L5alHiEHA.592@.TK2MSFTNGP11.phx.gbl...
> Hello, DBA outthere.
> I understand that SQL Server 2000 allows 1 default instance and up to 15
> named instances per server. I believe the default instance needs to be
> created first.
> Is there any reason to have more than 1 instance per server? Does having
> more than one instance affect the overall SQL server performance? SQL
> 2000 server also allows server alias if users to have different server
> naming.
> I usually create named instance for new installation instead of letting
> the SQL setup create the default instance. I had some run-ins with using
> named instance. Some not-so-well-prepared application setups looks into
> the registry for default instance
> (HKL\Software\Microsoft\MSSQLServer\MSSQLServer). If whatever they looks
> for is not there, the application will fail. Developers need to take
> into account that as SQL Server allows DBA to create either default or
> named instance or both.
> In any event, give share your thoughts on using default or named instance.
> Thanks.
> JJ.