MMC.EXE -Application Error

--Using SQL Server 2000 standard edition with SP3 on Windows 2000 Server
I am getting an error when I try to copy the data from a table to a text fil
e using a DTS Package. I am simply creating a connection to the database (s
ource) where the table exists and then creating another connection to the te
xt file (destination). The
properties of the text file are comma for the column delimiter, double quote
s for the text qualifers and first row contains column names. So after crea
ting the two connections I then create the 'Transform Data Task' (black arro
w going from the source to
the destination). I then go to the properties of the 'Transform Data Task'.
On the 'Source' tab I select the table I want to copy. I can preview the
data with no problems. I then click on the 'Destination' tab to define the
colmns. I click 'populate
from source' (it populates from the source) and then click 'execute'. This
is where the problem happens. It doesn't define the columns in the 'Destina
tion' tab. It is blank in the white space below. When I click the 'Define
Columns' button to try def
ine the columns again, I receive the following error in a pop up window:
In the Title Bar of the pop up window it says: MMC.EXE - Application Error
In the main part of the window it says: The instruction at 0x4173d23a" refe
renced memory at "0x01521e90". The memory could not be "written". Click on
OK to terminate the program
I click OK, and then it boots me out of Enterprise Manager.
In the 'disconnected edit' properties for the text file destination connecti
on, I have set the OLE DB Properties 'max characters per delimited column' f
rom 255 to 8000 to set if that is the problem since I have some columns that
are varchar 255. Still ge
t the same error.
I appreciate any help in advance to try resolving this problem.This error occurs when you apply SP3 or SP3a to your server. Article 814113
addresses this problem and then tells you to go to article 821277 for the p
atch downloads. You have to apply a cumulative security patch which creates
a problem with passwords o
n sql logins so you have to apply a small patch to fix that. I applied both
hotfixes in a test environment and it fixed the error. Hopefully it doesn'
t break anything else. Also, you have to apply these hotfixes to sql server
2000 with SP3 or SP3a and
also to workstations who are just running the client.
"IKE" wrote:

> --Using SQL Server 2000 standard edition with SP3 on Windows 2000 Server
> I am getting an error when I try to copy the data from a table to a text file usin
g a DTS Package. I am simply creating a connection to the database (source) where t
he table exists and then creating another connection to the text file (destination).
T
he properties of the text file are comma for the column delimiter, double qu
otes for the text qualifers and first row contains column names. So after c
reating the two connections I then create the 'Transform Data Task' (black a
rrow going from the source
to the destination). I then go to the properties of the 'Transform Data Tas
k'. On the 'Source' tab I select the table I want to copy. I can preview t
he data with no problems. I then click on the 'Destination' tab to define t
he colmns. I click 'popula
te from source' (it populates from the source) and then click 'execute'. Th
is is where the problem happens. It doesn't define the columns in the 'Dest
ination' tab. It is blank in the white space below. When I click the 'Defi
ne Columns' button to try d
efine the columns again, I receive the following error in a pop up window:
> In the Title Bar of the pop up window it says: MMC.EXE - Application Erro
r
> In the main part of the window it says: The instruction at 0x4173d23a" re
ferenced memory at "0x01521e90". The memory could not be "written". Click
on OK to terminate the program
> I click OK, and then it boots me out of Enterprise Manager.
> In the 'disconnected edit' properties for the text file destination connection, I
have set the OLE DB Properties 'max characters per delimited column' from 255 to 800
0 to set if that is the problem since I have some columns that are varchar 255. Sti
ll
get the same error.
> I appreciate any help in advance to try resolving this problem.
>
>

MMC.EXE -Application Error

--Using SQL Server 2000 standard edition with SP3 on Windows 2000 Server
I am getting an error when I try to copy the data from a table to a text file using a DTS Package. I am simply creating a connection to the database (source) where the table exists and then creating another connection to the text file (destination). The
properties of the text file are comma for the column delimiter, double quotes for the text qualifers and first row contains column names. So after creating the two connections I then create the 'Transform Data Task' (black arrow going from the source to
the destination). I then go to the properties of the 'Transform Data Task'. On the 'Source' tab I select the table I want to copy. I can preview the data with no problems. I then click on the 'Destination' tab to define the colmns. I click 'populate
from source' (it populates from the source) and then click 'execute'. This is where the problem happens. It doesn't define the columns in the 'Destination' tab. It is blank in the white space below. When I click the 'Define Columns' button to try def
ine the columns again, I receive the following error in a pop up window:
In the Title Bar of the pop up window it says: MMC.EXE - Application Error
In the main part of the window it says: The instruction at 0x4173d23a" referenced memory at "0x01521e90". The memory could not be "written". Click on OK to terminate the program
I click OK, and then it boots me out of Enterprise Manager.
In the 'disconnected edit' properties for the text file destination connection, I have set the OLE DB Properties 'max characters per delimited column' from 255 to 8000 to set if that is the problem since I have some columns that are varchar 255. Still ge
t the same error.
I appreciate any help in advance to try resolving this problem.
This error occurs when you apply SP3 or SP3a to your server. Article 814113 addresses this problem and then tells you to go to article 821277 for the patch downloads. You have to apply a cumulative security patch which creates a problem with passwords o
n sql logins so you have to apply a small patch to fix that. I applied both hotfixes in a test environment and it fixed the error. Hopefully it doesn't break anything else. Also, you have to apply these hotfixes to sql server 2000 with SP3 or SP3a and
also to workstations who are just running the client.
"IKE" wrote:

> --Using SQL Server 2000 standard edition with SP3 on Windows 2000 Server
> I am getting an error when I try to copy the data from a table to a text file using a DTS Package. I am simply creating a connection to the database (source) where the table exists and then creating another connection to the text file (destination). T
he properties of the text file are comma for the column delimiter, double quotes for the text qualifers and first row contains column names. So after creating the two connections I then create the 'Transform Data Task' (black arrow going from the source
to the destination). I then go to the properties of the 'Transform Data Task'. On the 'Source' tab I select the table I want to copy. I can preview the data with no problems. I then click on the 'Destination' tab to define the colmns. I click 'popula
te from source' (it populates from the source) and then click 'execute'. This is where the problem happens. It doesn't define the columns in the 'Destination' tab. It is blank in the white space below. When I click the 'Define Columns' button to try d
efine the columns again, I receive the following error in a pop up window:
> In the Title Bar of the pop up window it says: MMC.EXE - Application Error
> In the main part of the window it says: The instruction at 0x4173d23a" referenced memory at "0x01521e90". The memory could not be "written". Click on OK to terminate the program
> I click OK, and then it boots me out of Enterprise Manager.
> In the 'disconnected edit' properties for the text file destination connection, I have set the OLE DB Properties 'max characters per delimited column' from 255 to 8000 to set if that is the problem since I have some columns that are varchar 255. Still
get the same error.
> I appreciate any help in advance to try resolving this problem.
>
>

MMC 3.0 and SQL 2000

I am to install MMC 3.0 to a server (Server 2003 Standard Edition SP1) with
SQL 2000 Sp4. I would like to know if Server Enterprise Manager works under
MMC 3.0.
--
Regards
Rasmus SöderlundHi Rasmus
EM seems to work fine with MMC 3.0
John
"Rasmus" wrote:
> I am to install MMC 3.0 to a server (Server 2003 Standard Edition SP1) with
> SQL 2000 Sp4. I would like to know if Server Enterprise Manager works under
> MMC 3.0.
> --
> Regards
>
> Rasmus Söderlund

Mixing Types

Hello Group,
our company had a database on SQL Server 2000 Standard as the source for a
Report Server 2000 Standard. Well, the source databases had to be moved to a
brand new server. As it happened, the SQL Server 2000 on the new server is
Enterprise. Now, the report server will not work. We changed the connection
strings for the reports to point to the new server but no good. We just keep
getting "server not trusted".
Does the type of database server matter to the report server?
RichFirst, I assume that it is just the data that is an issue. Not the
reportserver database itself (where Report server keeps its metadata/object
caching).
My guess is that something else is going on with regards to the security. If
you are using integrated security there might be some issue with RS server
passing on credentials to
What I prefer to do is to have a read only SQL login. I use that for
credentials. I just use the windows domain login to determine who gets to
run what report.
It does not matter in the least where the data is coming from. I report off
of SQL Server standard, SQL Server Enterprise, Sybase, In-SQL (a real time
control historian).
Now, if you are not even having Report Manager come up (i.e. you never even
get where you can select the report to run) then it sounds like RS database
was moved. Again, you have a configuration/security problem going on.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Rich" <Rich@.discussions.microsoft.com> wrote in message
news:E44CB1AD-A386-40E2-BBE6-F1BB1872F817@.microsoft.com...
> Hello Group,
> our company had a database on SQL Server 2000 Standard as the source for a
> Report Server 2000 Standard. Well, the source databases had to be moved
> to a
> brand new server. As it happened, the SQL Server 2000 on the new server
> is
> Enterprise. Now, the report server will not work. We changed the
> connection
> strings for the reports to point to the new server but no good. We just
> keep
> getting "server not trusted".
> Does the type of database server matter to the report server?
> Rich|||Hello Bruce,
thanks...the Report Manger comes up just fine. It displays the folders and
reports and user just like always. I thought that if I changed the
Connection String in the Report Manager, this would be enough. I need to
come up with a stradigy as to how to narrow down the location of the problem.
Rich
"Bruce L-C [MVP]" wrote:
> First, I assume that it is just the data that is an issue. Not the
> reportserver database itself (where Report server keeps its metadata/object
> caching).
> My guess is that something else is going on with regards to the security. If
> you are using integrated security there might be some issue with RS server
> passing on credentials to
> What I prefer to do is to have a read only SQL login. I use that for
> credentials. I just use the windows domain login to determine who gets to
> run what report.
> It does not matter in the least where the data is coming from. I report off
> of SQL Server standard, SQL Server Enterprise, Sybase, In-SQL (a real time
> control historian).
> Now, if you are not even having Report Manager come up (i.e. you never even
> get where you can select the report to run) then it sounds like RS database
> was moved. Again, you have a configuration/security problem going on.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Rich" <Rich@.discussions.microsoft.com> wrote in message
> news:E44CB1AD-A386-40E2-BBE6-F1BB1872F817@.microsoft.com...
> > Hello Group,
> >
> > our company had a database on SQL Server 2000 Standard as the source for a
> > Report Server 2000 Standard. Well, the source databases had to be moved
> > to a
> > brand new server. As it happened, the SQL Server 2000 on the new server
> > is
> > Enterprise. Now, the report server will not work. We changed the
> > connection
> > strings for the reports to point to the new server but no good. We just
> > keep
> > getting "server not trusted".
> >
> > Does the type of database server matter to the report server?
> >
> > Rich
>
>sql

Mixed environments - SQL 2000 Standard & Enterprise?

We are upgrading a production database server to new hardware. The server is currently running SQL Server 2000 Standard Edition. We are thinking about installing SQL Server 2000 Enterprise Edition, however that would mean the test server (2000 Standard) and production server (2000 Enterprise) have different edtions of SQL Server. How much of a risk does this present? Later in the year we would upgrade test to SQL Server 2000 EE, but for a couple of months the environments would be different.

Thanks, DaveThere would be no side-effect for going from std to ent at all.|||The only problem I can forsee would be if you use a feature that only exists in Enterprise Edition. Most of the ones I can think of off the top of my head do not affect code, though (clustering, log shipping).|||I would use the SQL Server Dev Edition for the test environment since it has the full functionality as SQL Server Ent like log shipping.

Missing table log_shipping_monitor table

We upgraded SQL Server from standard to enterprise edition. When attempting to setup a maintenance plan we got an error 208: Invalid object name: msdb.dbo.log_shipping_monitor.
The table log_shipping_monitor doesn't exist in the msdb database.
Any ideas?
what happens if you appy/re-apply the latest sp.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"John M. Snarski" <John M. Snarski@.discussions.microsoft.com> wrote in
message news:8C1CFC6B-49B9-44A9-8FDC-E5A463C6E1D7@.microsoft.com...
> We upgraded SQL Server from standard to enterprise edition. When
attempting to setup a maintenance plan we got an error 208: Invalid object
name: msdb.dbo.log_shipping_monitor.
> The table log_shipping_monitor doesn't exist in the msdb database.
> Any ideas?
|||no change
"Hilary Cotter" wrote:

> what happens if you appy/re-apply the latest sp.
> --
> Hilary Cotter
> Looking for a book on SQL Server replication?
> http://www.nwsu.com/0974973602.html
>
> "John M. Snarski" <John M. Snarski@.discussions.microsoft.com> wrote in
> message news:8C1CFC6B-49B9-44A9-8FDC-E5A463C6E1D7@.microsoft.com...
> attempting to setup a maintenance plan we got an error 208: Invalid object
> name: msdb.dbo.log_shipping_monitor.
>
>

Missing Features In Standard Edition X64?

Hi all

In BOL in the features per version section it states that certain features available in the 32-bit version of Std Edition is not available in the 64-bit version. Eg. Database Mail, Query Editor, Query Designer etc.

I have downloaded the latest BOL (May 2007) and installed it and it still says certain features are not available in X64.

However I configured Database Mail on Std Edition X64 and it works 100%. Had some issues with SQLAgent using it but Service Pack 2 solved the problem.

Query Editor and Designer works even though Microsoft says it isn't available.

Is there any difference in the tools or features available in Std Edition 32-bit or 64-bit?

My other concern is what has Microsoft said is available and isn't?

From my tests I can't see anything missing. We are about to go purchase software and licenses and don't want to make the wrong choice.

Thanks
John

Currently, there are not 64 bit client tools pubically available to use with 64 bit SQL Server.

The 32 bit tools work just fine.

You most likely have installed and are using the 32 bit client tools.

|||

The following page in Books on Line is in error.

http://msdn2.microsoft.com/en-us/library/ms143761.aspx

I have submitted two requests for changes:

1. Remove the standard edition 64 bit column from the management tools section, and update the header of the SE 32 column to include SE 64. This says that tools features are the same in 32 and 64 bit.

2. SQL Mail is available only in 32 bit installations. DB Mail is available in 32 and 64 bit installs, whether they are standard or enterprise.

Thanks for pointing this out. I hope we can spare you further confusion.

jkh

|||

Thanks for getting back to me and clearing up the confusion.

Regards

John