Dear
we have a problem when installing MSSQL 2000 on a MS Windows Advanced Server in Cluster
We have a node 1 and a node 2 correct configured
so thats not the problem.
what we did prior to install MSSQL
We did run " comclust " on node 1 ( dos box is open on node 1 ), then we go to node 2 and run " comclust ", we close the dos box on node 2, and then the dos box on node
then we entered the cd in de cd-rom drive from node 1
and we pushed setup.bat
then we configured and aswered all questions correctly.
Also the SQL login name has " domain admin rights "
then we get the message " installing blah blah ... this will take a few minutes "
then after a few minutes we get a message with an error " ERROR: 15457; SEVERITY 0; State 0. "
and installation stops.
I have searched the internet and a thousend message boards about this problem, but non where succesful.
They are saying that this is not an error message but an informational message ...
And that it can be fixed due running reconfigure command in the query annalyzer.
But we can't connect to the sql due no service installed !!
is there someone who can help with this problem.
I really cant see a sollution for this problem.
log:
2003-10-07 15:50:05.13 server SQL server listening on TCP, Shared Memory, Named Pipes.
2003-10-07 15:50:05.13 server SQL server listening on 192.168.0.1:1433, 10.2.101.15:1433, 10.2.101.17:1433, 127.0.0.1:1433.
2003-10-07 15:50:05.14 server SQL Server is ready for client connections
2003-10-07 15:50:05.16 spid5 Starting up database 'tempdb'.
2003-10-07 15:50:05.19 spid4 Warning ******************
2003-10-07 15:50:05.19 spid4 Attempting to change default collation to Latin1_General_CS_AS.
2003-10-07 15:50:07.50 spid4 Clustered index restored for master.sysdatabases.
2003-10-07 15:50:07.53 spid4 Non-clustered index restored for master.sysobjects.
2003-10-07 15:50:07.55 spid4 Non-clustered index restored for master.sysobjects.
2003-10-07 15:50:07.57 spid4 index restored for master.syscolumns.
2003-10-07 15:50:07.58 spid4 index restored for master.systypes.
2003-10-07 15:50:07.58 spid4 index restored for master.sysusers.
2003-10-07 15:50:07.75 spid4 index restored for master.sysproperties.
2003-10-07 15:50:07.75 spid4 index restored for master.sysfulltextcatalogs.
2003-10-07 15:50:07.78 spid4 index restored for master.sysxlogins.
2003-10-07 15:50:07.85 spid4 index restored for master.sysdevices.
2003-10-07 15:50:07.86 spid4 index restored for master.sysservers.
2003-10-07 15:50:07.88 spid4 index restored for master.syslanguages.
2003-10-07 15:50:07.89 spid4 index restored for master.syscharsets.
2003-10-07 15:50:07.89 spid4 index restored for master.sysfilegroups.
2003-10-07 15:50:08.97 spid4 index restored for master.spt_values.
2003-10-07 15:50:08.97 spid4 index restored for master.spt_datatype_info_ext.
2003-10-07 15:50:08.97 spid4 index restored for master.MSreplication_options.
2003-10-07 15:50:08.99 spid4 index restored for master.spt_datatype_info.
2003-10-07 15:50:09.02 spid4 Non-clustered index restored for tempdb.sysobjects.
2003-10-07 15:50:09.02 spid4 Non-clustered index restored for tempdb.sysobjects.
2003-10-07 15:50:09.02 spid4 index restored for tempdb.syscolumns.
2003-10-07 15:50:09.02 spid4 index restored for tempdb.systypes.
2003-10-07 15:50:09.02 spid4 index restored for tempdb.sysusers.
2003-10-07 15:50:09.03 spid4 index restored for tempdb.sysproperties.
2003-10-07 15:50:09.03 spid4 index restored for tempdb.sysfulltextcatalogs.
2003-10-07 15:50:09.03 spid4 index restored for tempdb.sysfilegroups.
2003-10-07 15:50:09.05 spid4 Non-clustered index restored for model.sysobjects.
2003-10-07 15:50:09.05 spid4 Non-clustered index restored for model.sysobjects.
2003-10-07 15:50:09.07 spid4 index restored for model.syscolumns.
2003-10-07 15:50:09.07 spid4 index restored for model.systypes.
2003-10-07 15:50:09.08 spid4 index restored for model.sysusers.
2003-10-07 15:50:09.08 spid4 index restored for model.sysproperties.
2003-10-07 15:50:09.10 spid4 index restored for model.sysfulltextcatalogs.
2003-10-07 15:50:09.10 spid4 index restored for model.sysfilegroups.
2003-10-07 15:50:09.27 spid4 Non-clustered index restored for msdb.sysobjects.
2003-10-07 15:50:09.30 spid4 Non-clustered index restored for msdb.sysobjects.
2003-10-07 15:50:09.35 spid4 index restored for msdb.syscolumns.
2003-10-07 15:50:09.35 spid4 index restored for msdb.systypes.
2003-10-07 15:50:09.38 spid4 index restored for msdb.sysusers.
2003-10-07 15:50:09.38 spid4 index restored for msdb.sysproperties.
2003-10-07 15:50:09.38 spid4 index restored for msdb.sysfulltextcatalogs.
2003-10-07 15:50:09.38 spid4 index restored for msdb.sysfilegroups.
2003-10-07 15:50:09.39 spid4 index restored for msdb.sysjobschedules.
2003-10-07 15:50:09.41 spid4 index restored for msdb.syscategories.
2003-10-07 15:50:09.41 spid4 index restored for msdb.systargetservers.
2003-10-07 15:50:09.41 spid4 index restored for msdb.systargetservergroups.
2003-10-07 15:50:09.42 spid4 index restored for msdb.RTblDatabaseVersion.
2003-10-07 15:50:09.44 spid4 index restored for msdb.sysalerts.
2003-10-07 15:50:09.44 spid4 index restored for msdb.sysoperators.
2003-10-07 15:50:09.44 spid4 index restored for msdb.syscachedcredentials.
2003-10-07 15:50:09.47 spid4 index restored for msdb.logmarkhistory.
2003-10-07 15:50:09.53 spid4 index restored for msdb.RTblNamedObj.
2003-10-07 15:50:09.53 spid4 index restored for msdb.sysdtscategories.
2003-10-07 15:50:09.53 spid4 index restored for msdb.sysdbmaintplan_databases.
2003-10-07 15:50:09.53 spid4 index restored for msdb.mswebtasks.
2003-10-07 15:50:09.55 spid4 index restored for msdb.RTblProps.
2003-10-07 15:50:09.55 spid4 index restored for msdb.RTblRelshipProps.
2003-10-07 15:50:09.55 spid4 index restored for msdb.sysdownloadlist.
2003-10-07 15:50:09.57 spid4 index restored for msdb.sysjobs.
2003-10-07 15:50:09.57 spid4 index restored for msdb.sysjobsteps.
2003-10-07 15:50:09.61 spid4 Non-clustered index restored for pubs.sysobjects.
2003-10-07 15:50:09.61 spid4 Non-clustered index restored for pubs.sysobjects.
2003-10-07 15:50:09.63 spid4 index restored for pubs.syscolumns.
2003-10-07 15:50:09.64 spid4 index restored for pubs.systypes.
2003-10-07 15:50:09.64 spid4 index restored for pubs.sysusers.
2003-10-07 15:50:09.64 spid4 index restored for pubs.sysproperties.
2003-10-07 15:50:09.64 spid4 index restored for pubs.sysfulltextcatalogs.
2003-10-07 15:50:09.64 spid4 index restored for pubs.sysfilegroups.
2003-10-07 15:50:09.67 spid4 index restored for pubs.titleauthor.
2003-10-07 15:50:09.69 spid4 index restored for pubs.stores.
2003-10-07 15:50:09.69 spid4 index restored for pubs.sales.
2003-10-07 15:50:09.71 spid4 index restored for pubs.roysched.
2003-10-07 15:50:09.72 spid4 index restored for pubs.pub_info.
2003-10-07 15:50:09.75 spid4 index restored for pubs.employee.
2003-10-07 15:50:09.78 spid4 index restored for pubs.authors.
2003-10-07 15:50:09.78 spid4 index restored for pubs.publishers.
2003-10-07 15:50:09.80 spid4 index restored for pubs.titles.
2003-10-07 15:50:09.85 spid4 Non-clustered index restored for Northwind.sysobjects.
2003-10-07 15:50:09.85 spid4 Non-clustered index restored for Northwind.sysobjects.
2003-10-07 15:50:09.88 spid4 index restored for Northwind.syscolumns.
2003-10-07 15:50:09.88 spid4 index restored for Northwind.systypes.
2003-10-07 15:50:09.88 spid4 index restored for Northwind.sysusers.
2003-10-07 15:50:09.88 spid4 index restored for Northwind.sysproperties.
2003-10-07 15:50:09.88 spid4 index restored for Northwind.sysfulltextcatalogs.
2003-10-07 15:50:09.89 spid4 index restored for Northwind.sysfilegroups.
2003-10-07 15:50:09.94 spid4 index restored for Northwind.Orders.
2003-10-07 15:50:09.94 spid4 index restored for Northwind.Products.
2003-10-07 15:50:09.96 spid4 index restored for Northwind.CustomerCustomerDemo.
2003-10-07 15:50:09.96 spid4 index restored for Northwind.CustomerDemographics.
2003-10-07 15:50:09.96 spid4 index restored for Northwind.Territories.
2003-10-07 15:50:09.96 spid4 index restored for Northwind.EmployeeTerritories.
2003-10-07 15:50:09.97 spid4 index restored for Northwind.Employees.
2003-10-07 15:50:09.97 spid4 index restored for Northwind.Categories.
2003-10-07 15:50:10.00 spid4 index restored for Northwind.Customers.
2003-10-07 15:50:10.02 spid4 index restored for Northwind.Suppliers.
2003-10-07 15:50:10.57 spid4 Default collation successfully changed.
2003-10-07 15:50:10.57 spid4 Recovery complete.
2003-10-07 15:50:10.57 spid4 Warning: override, autoexec procedures skipped.
2003-10-07 15:50:15.94 spid51 Error: 15457, Severity: 0, State: 1
2003-10-07 15:50:15.94 spid51 Configuration option 'allow updates' changed from 0 to 1. Run the RECONFIGURE statement to install..
2003-10-07 15:50:16.02 spid51 Error: 15457, Severity: 0, State: 1
2003-10-07 15:50:16.02 spid51 Configuration option 'allow updates' changed from 1 to 0. Run the RECONFIGURE statement to install..
2003-10-07 15:50:16.13 spid4 SQL Server is terminating due to 'stop' request from Service Control Manager.
Thanks in advance
KurtHowdy
Is it possible the install has completed and the service shutdown is part of that?
Cheers
SG|||ok found the sollution , workaround
on technet : PSS ID 318672
Q318672
hope this helps for other users|||This article was previously published under Q318672
BUG #: 236113 (SHILOH_BUGS)
SYMPTOMS
A Microsoft SQL Server 2000 virtual server set up on multiple nodes may fail with this error message:
Setup failed to perform the required operation on the cluster nodes
The Sqlstp.log file will also contain the following error messages.
NOTE: The Sqlstp.log file is located in the %WINDIR% folder of the node from which you run the Virtual Server Setup program.
CThreadPool::RunUntilCompleteHlpr WaitForMultipleObjects returned: 0
CThreadPool::RunUntilCompleteHlpr signaled thread [0xa4]
Thread [0xa4] exit code: [0x0]
CRemoteProcess::RunUntilComplete [0xa8] exit code: 2
Remote process exit code was '2' (NODE2).
...
...
CThreadPool::RunUntilComplete returned 2
CThreadPool::RunUntilComplete execution level=1, need execution: 0
One or more errors occurred while running the remote/unattended setups.
In the preceding error message, identify the remote node that has a remote process exit code of 2. In the preceding example, the remote node is NODE2. On the remote node, open the Sqlstpn.log file located in the %WINDIR% folder, and look for this error message:
13:50:08 Begin Action: ShowDlgInstanceName
13:50:20 End Action: ShowDlgInstanceName
13:50:20 ShowDlgInstanceName returned : -1
13:50:20 ShowDlgInstanceName: GetLastError returned: 50044
13:50:20 End Action DialogShowSdInstanceName
13:50:20 End Action ShowDialogs
13:50:20 Action CleanUpInstall:
13:50:20 StatsGenerate returned: 2
13:50:20 StatsGenerate (0x0,0x1,0xf00000,0x200,1033,0,0x0,0x1000000a,0,0, 0
13:50:20 StatsGenerate -1,cluster)
13:50:20 Installation Failed.
NOTE: You may receive the error message
Setup failed to perform the required operation on the cluster nodes
for causes other than the one described in this article. The only way to confirm if the error message is caused by the problem described in this article is to check the SQL Server setup logs and to compare the error footprint.
CAUSE
A race condition between the Setup program that is running on the first node (the node on which the Virtual Server set up is initiated) and the Setup programs that are running remotely on the other nodes.
The SQL Server 2000 Virtual Server set up involves a main set up process that starts one unattended installation for every node that is part of the virtual server. If the number of the unattended installations is two, or more, the race condition may occur.
WORKAROUND
Install a single node virtual server by running the Setup program on any node of the cluster. For more information, see the "How to install a one-node failover cluster (Setup)" topic in SQL Server 2000 Books Online.
Add the second node to the virtual server by running the Setup program again on the node you used in step 1. For more information, see the "How to add nodes to an existing virtual server (Setup)" topic in SQL Server 2000 Books Online.
Repeat step 2 for any number of nodes that you want to add to the virtual server.
STATUS
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.
Additional query words: cluster install fails 50044
Keywords: kbbug KB318672
Technology: kbAudDeveloper kbSQLServ2000Search kbSQLServSearch
Showing posts with label advanced. Show all posts
Showing posts with label advanced. Show all posts
Friday, March 30, 2012
Wednesday, March 28, 2012
mssearch.exe easting up memory
Hi ,
Running SQL 2000 on Windows Advanced Server 2003 Standard. If I leave it up
for three days, the mssearch.exe job just continues to eat up more memory
until the machine runs out of it needing for the mssearch.exe job to be
ended. Then the mssearch.exe runs again and the cycle continues.
I observered that everytime our .net app touches the sql server database,
that is when this mssearch.exe job stays and start to eat up memory. A
google search reveals that open cursors to the database or a web user
creates a link and does nothing causes this mssearch.exe to go up and grow
and grow.
Is there a fix for this or a workaround?
Thanks,
RdR
You should contact Microsoft Product Support and have them take a look at
MSSearch.
Adrian
"RdR" <rrosario@.datamirror.com> wrote in message
news:GWRde.4408$5u4.15748@.nnrp1.uunet.ca...
> Hi ,
> Running SQL 2000 on Windows Advanced Server 2003 Standard. If I leave it
> up for three days, the mssearch.exe job just continues to eat up more
> memory until the machine runs out of it needing for the mssearch.exe job
> to be ended. Then the mssearch.exe runs again and the cycle continues.
> I observered that everytime our .net app touches the sql server database,
> that is when this mssearch.exe job stays and start to eat up memory. A
> google search reveals that open cursors to the database or a web user
> creates a link and does nothing causes this mssearch.exe to go up and grow
> and grow.
> Is there a fix for this or a workaround?
> Thanks,
> RdR
>
Running SQL 2000 on Windows Advanced Server 2003 Standard. If I leave it up
for three days, the mssearch.exe job just continues to eat up more memory
until the machine runs out of it needing for the mssearch.exe job to be
ended. Then the mssearch.exe runs again and the cycle continues.
I observered that everytime our .net app touches the sql server database,
that is when this mssearch.exe job stays and start to eat up memory. A
google search reveals that open cursors to the database or a web user
creates a link and does nothing causes this mssearch.exe to go up and grow
and grow.
Is there a fix for this or a workaround?
Thanks,
RdR
You should contact Microsoft Product Support and have them take a look at
MSSearch.
Adrian
"RdR" <rrosario@.datamirror.com> wrote in message
news:GWRde.4408$5u4.15748@.nnrp1.uunet.ca...
> Hi ,
> Running SQL 2000 on Windows Advanced Server 2003 Standard. If I leave it
> up for three days, the mssearch.exe job just continues to eat up more
> memory until the machine runs out of it needing for the mssearch.exe job
> to be ended. Then the mssearch.exe runs again and the cycle continues.
> I observered that everytime our .net app touches the sql server database,
> that is when this mssearch.exe job stays and start to eat up memory. A
> google search reveals that open cursors to the database or a web user
> creates a link and does nothing causes this mssearch.exe to go up and grow
> and grow.
> Is there a fix for this or a workaround?
> Thanks,
> RdR
>
mssearch.exe easting up memory
Hi ,
Running SQL 2000 on Windows Advanced Server 2003 Standard. If I leave it up
for three days, the mssearch.exe job just continues to eat up more memory
until the machine runs out of it needing for the mssearch.exe job to be
ended. Then the mssearch.exe runs again and the cycle continues.
I observered that everytime our .net app touches the sql server database,
that is when this mssearch.exe job stays and start to eat up memory. A
google search reveals that open cursors to the database or a web user
creates a link and does nothing causes this mssearch.exe to go up and grow
and grow.
Is there a fix for this or a workaround?
Thanks,
RdRYou should contact Microsoft Product Support and have them take a look at
MSSearch.
Adrian
"RdR" <rrosario@.datamirror.com> wrote in message
news:GWRde.4408$5u4.15748@.nnrp1.uunet.ca...
> Hi ,
> Running SQL 2000 on Windows Advanced Server 2003 Standard. If I leave it
> up for three days, the mssearch.exe job just continues to eat up more
> memory until the machine runs out of it needing for the mssearch.exe job
> to be ended. Then the mssearch.exe runs again and the cycle continues.
> I observered that everytime our .net app touches the sql server database,
> that is when this mssearch.exe job stays and start to eat up memory. A
> google search reveals that open cursors to the database or a web user
> creates a link and does nothing causes this mssearch.exe to go up and grow
> and grow.
> Is there a fix for this or a workaround?
> Thanks,
> RdR
>
Running SQL 2000 on Windows Advanced Server 2003 Standard. If I leave it up
for three days, the mssearch.exe job just continues to eat up more memory
until the machine runs out of it needing for the mssearch.exe job to be
ended. Then the mssearch.exe runs again and the cycle continues.
I observered that everytime our .net app touches the sql server database,
that is when this mssearch.exe job stays and start to eat up memory. A
google search reveals that open cursors to the database or a web user
creates a link and does nothing causes this mssearch.exe to go up and grow
and grow.
Is there a fix for this or a workaround?
Thanks,
RdRYou should contact Microsoft Product Support and have them take a look at
MSSearch.
Adrian
"RdR" <rrosario@.datamirror.com> wrote in message
news:GWRde.4408$5u4.15748@.nnrp1.uunet.ca...
> Hi ,
> Running SQL 2000 on Windows Advanced Server 2003 Standard. If I leave it
> up for three days, the mssearch.exe job just continues to eat up more
> memory until the machine runs out of it needing for the mssearch.exe job
> to be ended. Then the mssearch.exe runs again and the cycle continues.
> I observered that everytime our .net app touches the sql server database,
> that is when this mssearch.exe job stays and start to eat up memory. A
> google search reveals that open cursors to the database or a web user
> creates a link and does nothing causes this mssearch.exe to go up and grow
> and grow.
> Is there a fix for this or a workaround?
> Thanks,
> RdR
>
mssearch.exe easting up memory
Hi ,
Running SQL 2000 on Windows Advanced Server 2003 Standard. If I leave it up
for three days, the mssearch.exe job just continues to eat up more memory
until the machine runs out of it needing for the mssearch.exe job to be
ended. Then the mssearch.exe runs again and the cycle continues.
I observered that everytime our .net app touches the sql server database,
that is when this mssearch.exe job stays and start to eat up memory. A
google search reveals that open cursors to the database or a web user
creates a link and does nothing causes this mssearch.exe to go up and grow
and grow.
Is there a fix for this or a workaround?
Thanks,
RdRYou should contact Microsoft Product Support and have them take a look at
MSSearch.
Adrian
"RdR" <rrosario@.datamirror.com> wrote in message
news:GWRde.4408$5u4.15748@.nnrp1.uunet.ca...
> Hi ,
> Running SQL 2000 on Windows Advanced Server 2003 Standard. If I leave it
> up for three days, the mssearch.exe job just continues to eat up more
> memory until the machine runs out of it needing for the mssearch.exe job
> to be ended. Then the mssearch.exe runs again and the cycle continues.
> I observered that everytime our .net app touches the sql server database,
> that is when this mssearch.exe job stays and start to eat up memory. A
> google search reveals that open cursors to the database or a web user
> creates a link and does nothing causes this mssearch.exe to go up and grow
> and grow.
> Is there a fix for this or a workaround?
> Thanks,
> RdR
>sql
Running SQL 2000 on Windows Advanced Server 2003 Standard. If I leave it up
for three days, the mssearch.exe job just continues to eat up more memory
until the machine runs out of it needing for the mssearch.exe job to be
ended. Then the mssearch.exe runs again and the cycle continues.
I observered that everytime our .net app touches the sql server database,
that is when this mssearch.exe job stays and start to eat up memory. A
google search reveals that open cursors to the database or a web user
creates a link and does nothing causes this mssearch.exe to go up and grow
and grow.
Is there a fix for this or a workaround?
Thanks,
RdRYou should contact Microsoft Product Support and have them take a look at
MSSearch.
Adrian
"RdR" <rrosario@.datamirror.com> wrote in message
news:GWRde.4408$5u4.15748@.nnrp1.uunet.ca...
> Hi ,
> Running SQL 2000 on Windows Advanced Server 2003 Standard. If I leave it
> up for three days, the mssearch.exe job just continues to eat up more
> memory until the machine runs out of it needing for the mssearch.exe job
> to be ended. Then the mssearch.exe runs again and the cycle continues.
> I observered that everytime our .net app touches the sql server database,
> that is when this mssearch.exe job stays and start to eat up memory. A
> google search reveals that open cursors to the database or a web user
> creates a link and does nothing causes this mssearch.exe to go up and grow
> and grow.
> Is there a fix for this or a workaround?
> Thanks,
> RdR
>sql
Saturday, February 25, 2012
MSDTC fails on Windows 2000 Advanced Server SP4
I have a VB6 application that uses MTS in a COM+ package for
transaction based processing over MSDTC. This application was working
fine when run from the SQL Server machine on Windows 2000 Advanced
Server until the latest security updates were installed. Now the
application fails to connect to SQL Server when the call is made inside
a transaction context within MTS/COM+
I have verified that MSDTC is started
The DTCTester tool runs successfully
RPC port 135 is open
This application runs fine on a Windows 2000 Server machine with SP4.
What is different about Windows 2000 Advanced Server such that it no
longer works after applying security updates (SP4)?
?s your SQL server and application server are in same domain, do you have
firewall etc between SQL Server and appl. server?
We had problems after we install Windows 2003 SP1 with MSDTC, we select No
Authantication Required and the problem is gone. Maybe because of you have
applied security patches you are having the same problem.
Check out:
http://support.microsoft.com/?id=883960
Hope this helps.
"dhalb@.comcast.net" wrote:
> I have a VB6 application that uses MTS in a COM+ package for
> transaction based processing over MSDTC. This application was working
> fine when run from the SQL Server machine on Windows 2000 Advanced
> Server until the latest security updates were installed. Now the
> application fails to connect to SQL Server when the call is made inside
> a transaction context within MTS/COM+
> I have verified that MSDTC is started
> The DTCTester tool runs successfully
> RPC port 135 is open
> This application runs fine on a Windows 2000 Server machine with SP4.
> What is different about Windows 2000 Advanced Server such that it no
> longer works after applying security updates (SP4)?
>
transaction based processing over MSDTC. This application was working
fine when run from the SQL Server machine on Windows 2000 Advanced
Server until the latest security updates were installed. Now the
application fails to connect to SQL Server when the call is made inside
a transaction context within MTS/COM+
I have verified that MSDTC is started
The DTCTester tool runs successfully
RPC port 135 is open
This application runs fine on a Windows 2000 Server machine with SP4.
What is different about Windows 2000 Advanced Server such that it no
longer works after applying security updates (SP4)?
?s your SQL server and application server are in same domain, do you have
firewall etc between SQL Server and appl. server?
We had problems after we install Windows 2003 SP1 with MSDTC, we select No
Authantication Required and the problem is gone. Maybe because of you have
applied security patches you are having the same problem.
Check out:
http://support.microsoft.com/?id=883960
Hope this helps.
"dhalb@.comcast.net" wrote:
> I have a VB6 application that uses MTS in a COM+ package for
> transaction based processing over MSDTC. This application was working
> fine when run from the SQL Server machine on Windows 2000 Advanced
> Server until the latest security updates were installed. Now the
> application fails to connect to SQL Server when the call is made inside
> a transaction context within MTS/COM+
> I have verified that MSDTC is started
> The DTCTester tool runs successfully
> RPC port 135 is open
> This application runs fine on a Windows 2000 Server machine with SP4.
> What is different about Windows 2000 Advanced Server such that it no
> longer works after applying security updates (SP4)?
>
Labels:
advanced,
application,
based,
database,
fails,
fortransaction,
microsoft,
msdtc,
mts,
mysql,
oracle,
package,
processing,
run,
server,
sp4,
sql,
vb6,
windows,
workingfine
MSDTC fails on Windows 2000 Advanced Server SP4
I have a VB6 application that uses MTS in a COM+ package for
transaction based processing over MSDTC. This application was working
fine when run from the SQL Server machine on Windows 2000 Advanced
Server until the latest security updates were installed. Now the
application fails to connect to SQL Server when the call is made inside
a transaction context within MTS/COM+
I have verified that MSDTC is started
The DTCTester tool runs successfully
RPC port 135 is open
This application runs fine on a Windows 2000 Server machine with SP4.
What is different about Windows 2000 Advanced Server such that it no
longer works after applying security updates (SP4)'İs your SQL server and application server are in same domain, do you have
firewall etc between SQL Server and appl. server?
We had problems after we install Windows 2003 SP1 with MSDTC, we select No
Authantication Required and the problem is gone. Maybe because of you have
applied security patches you are having the same problem.
Check out:
http://support.microsoft.com/?id=883960
Hope this helps.
"dhalb@.comcast.net" wrote:
> I have a VB6 application that uses MTS in a COM+ package for
> transaction based processing over MSDTC. This application was working
> fine when run from the SQL Server machine on Windows 2000 Advanced
> Server until the latest security updates were installed. Now the
> application fails to connect to SQL Server when the call is made inside
> a transaction context within MTS/COM+
> I have verified that MSDTC is started
> The DTCTester tool runs successfully
> RPC port 135 is open
> This application runs fine on a Windows 2000 Server machine with SP4.
> What is different about Windows 2000 Advanced Server such that it no
> longer works after applying security updates (SP4)'
>
transaction based processing over MSDTC. This application was working
fine when run from the SQL Server machine on Windows 2000 Advanced
Server until the latest security updates were installed. Now the
application fails to connect to SQL Server when the call is made inside
a transaction context within MTS/COM+
I have verified that MSDTC is started
The DTCTester tool runs successfully
RPC port 135 is open
This application runs fine on a Windows 2000 Server machine with SP4.
What is different about Windows 2000 Advanced Server such that it no
longer works after applying security updates (SP4)'İs your SQL server and application server are in same domain, do you have
firewall etc between SQL Server and appl. server?
We had problems after we install Windows 2003 SP1 with MSDTC, we select No
Authantication Required and the problem is gone. Maybe because of you have
applied security patches you are having the same problem.
Check out:
http://support.microsoft.com/?id=883960
Hope this helps.
"dhalb@.comcast.net" wrote:
> I have a VB6 application that uses MTS in a COM+ package for
> transaction based processing over MSDTC. This application was working
> fine when run from the SQL Server machine on Windows 2000 Advanced
> Server until the latest security updates were installed. Now the
> application fails to connect to SQL Server when the call is made inside
> a transaction context within MTS/COM+
> I have verified that MSDTC is started
> The DTCTester tool runs successfully
> RPC port 135 is open
> This application runs fine on a Windows 2000 Server machine with SP4.
> What is different about Windows 2000 Advanced Server such that it no
> longer works after applying security updates (SP4)'
>
MSDTC fails on Windows 2000 Advanced Server SP4
I have a VB6 application that uses MTS in a COM+ package for
transaction based processing over MSDTC. This application was working
fine when run from the SQL Server machine on Windows 2000 Advanced
Server until the latest security updates were installed. Now the
application fails to connect to SQL Server when the call is made inside
a transaction context within MTS/COM+
I have verified that MSDTC is started
The DTCTester tool runs successfully
RPC port 135 is open
This application runs fine on a Windows 2000 Server machine with SP4.
What is different about Windows 2000 Advanced Server such that it no
longer works after applying security updates (SP4)'?s your SQL server and application server are in same domain, do you have
firewall etc between SQL Server and appl. server?
We had problems after we install Windows 2003 SP1 with MSDTC, we select No
Authantication Required and the problem is gone. Maybe because of you have
applied security patches you are having the same problem.
Check out:
http://support.microsoft.com/?id=883960
Hope this helps.
"dhalb@.comcast.net" wrote:
> I have a VB6 application that uses MTS in a COM+ package for
> transaction based processing over MSDTC. This application was working
> fine when run from the SQL Server machine on Windows 2000 Advanced
> Server until the latest security updates were installed. Now the
> application fails to connect to SQL Server when the call is made inside
> a transaction context within MTS/COM+
> I have verified that MSDTC is started
> The DTCTester tool runs successfully
> RPC port 135 is open
> This application runs fine on a Windows 2000 Server machine with SP4.
> What is different about Windows 2000 Advanced Server such that it no
> longer works after applying security updates (SP4)'
>
transaction based processing over MSDTC. This application was working
fine when run from the SQL Server machine on Windows 2000 Advanced
Server until the latest security updates were installed. Now the
application fails to connect to SQL Server when the call is made inside
a transaction context within MTS/COM+
I have verified that MSDTC is started
The DTCTester tool runs successfully
RPC port 135 is open
This application runs fine on a Windows 2000 Server machine with SP4.
What is different about Windows 2000 Advanced Server such that it no
longer works after applying security updates (SP4)'?s your SQL server and application server are in same domain, do you have
firewall etc between SQL Server and appl. server?
We had problems after we install Windows 2003 SP1 with MSDTC, we select No
Authantication Required and the problem is gone. Maybe because of you have
applied security patches you are having the same problem.
Check out:
http://support.microsoft.com/?id=883960
Hope this helps.
"dhalb@.comcast.net" wrote:
> I have a VB6 application that uses MTS in a COM+ package for
> transaction based processing over MSDTC. This application was working
> fine when run from the SQL Server machine on Windows 2000 Advanced
> Server until the latest security updates were installed. Now the
> application fails to connect to SQL Server when the call is made inside
> a transaction context within MTS/COM+
> I have verified that MSDTC is started
> The DTCTester tool runs successfully
> RPC port 135 is open
> This application runs fine on a Windows 2000 Server machine with SP4.
> What is different about Windows 2000 Advanced Server such that it no
> longer works after applying security updates (SP4)'
>
Labels:
advanced,
application,
based,
database,
fails,
fortransaction,
microsoft,
msdtc,
mts,
mysql,
oracle,
package,
processing,
run,
server,
sp4,
sql,
vb6,
windows,
workingfine
Monday, February 20, 2012
MSDTC and SQL2000 clustered
Hi,
I'm in doubt about an installation of SQL Server 2000 (single istance hot standby) on a Win2000 Advanced Server 2 nodes cluster (2 processors per node).
I suppose MSDTC was not activated during SQL2000 setup.
Is it absolutely necessary?
Can I have problems?
In what case is it necessary?
Many thanks?Originally posted by nisant
Hi,
I'm in doubt about an installation of SQL Server 2000 (single istance hot standby) on a Win2000 Advanced Server 2 nodes cluster (2 processors per node).
I suppose MSDTC was not activated during SQL2000 setup.
Is it absolutely necessary?
Can I have problems?
In what case is it necessary?
Many thanks?
I had a problem in an active\active failover installation. MSDTC was not configured and was causing problems with the fail over function. Once I configured it as a shared resource, everything seemed fine. Hope this helps...|||True, make sure MSDTC has been started and working whenever any distributed transactions are in process.
For information refer to DB journal (http://www.databasejournal.com/features/mssql/article.php/1690901) article.
I'm in doubt about an installation of SQL Server 2000 (single istance hot standby) on a Win2000 Advanced Server 2 nodes cluster (2 processors per node).
I suppose MSDTC was not activated during SQL2000 setup.
Is it absolutely necessary?
Can I have problems?
In what case is it necessary?
Many thanks?Originally posted by nisant
Hi,
I'm in doubt about an installation of SQL Server 2000 (single istance hot standby) on a Win2000 Advanced Server 2 nodes cluster (2 processors per node).
I suppose MSDTC was not activated during SQL2000 setup.
Is it absolutely necessary?
Can I have problems?
In what case is it necessary?
Many thanks?
I had a problem in an active\active failover installation. MSDTC was not configured and was causing problems with the fail over function. Once I configured it as a shared resource, everything seemed fine. Hope this helps...|||True, make sure MSDTC has been started and working whenever any distributed transactions are in process.
For information refer to DB journal (http://www.databasejournal.com/features/mssql/article.php/1690901) article.
Subscribe to:
Posts (Atom)