OMWWIZE and Copy Database Wizard

Please help.
I am trying to move one of our production databases (MSSQL7) to a larger,
more powerful box running MSSQL2000. Each time I run the copy database
wizard, I get a failure with the error message reading "Failed to create the
share OMWWIZE."
What is this share? Why do I need it? Why would this step fail? Where should
it be? How do I fix this?
I say again, please help.
--
Kerry CarrollHave a look here
http://support.microsoft.com/default.aspx?scid=kb;en-us;q274463
--
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
"Good Try" <test@.not.com> wrote in message
news:eL59ym$vDHA.1576@.TK2MSFTNGP11.phx.gbl...
> Please help.
> I am trying to move one of our production databases (MSSQL7) to a larger,
> more powerful box running MSSQL2000. Each time I run the copy database
> wizard, I get a failure with the error message reading "Failed to create
the
> share OMWWIZE."
> What is this share? Why do I need it? Why would this step fail? Where
should
> it be? How do I fix this?
> I say again, please help.
> --
> Kerry Carroll
>

oledb wait type

We have a production server that's cpu is throttled, and requests are timing
out. After running the get_waitstats sp, OLEDB is at the top of the list in
wait type (99%).
How do I determine which spid is involved in an oledb wait type?
This is a Windows 2000 sp 3 box, running sql 2000.
If you query master..sysprocesses, you can get the spids,
wait types and wait times.
If you want to see what the spids are actually executing,
pre-SP3, you can use:
dbcc inputbuffer(spid)
If you are on SP3, you can use:
declare @.Handle binary(20)
select @.Handle = sql_handle
from sysprocesses
where spid = <spid>
select * from ::fn_get_sql(@.Handle)
-Sue
On Mon, 7 Feb 2005 14:51:02 -0800, Ken
<Ken@.discussions.microsoft.com> wrote:

>We have a production server that's cpu is throttled, and requests are timing
>out. After running the get_waitstats sp, OLEDB is at the top of the list in
>wait type (99%).
>How do I determine which spid is involved in an oledb wait type?
>This is a Windows 2000 sp 3 box, running sql 2000.
>
|||OLEDB waittype is an overloaded waittype to begin with, it is set for:
* linked server calls
* bulk insert
* running SQL Trace
* running 6.x to 7.0 or 2000 conversion imports
* materializing virtual tables like select * from master.dbo.sysprocesses
and select * from master.dbo.syslockinfo
Also this wait state is set differently, since it is set when the call is
entered and unset when the call is done, so when you start a BULK INSERT it
will be set, when you are done it is unset, bt you are not really waiting,
you are doing real work, only inside an OLE DB provider, for example BULK
INSERT is hosted in the IMPROV.DLL provider, SQL Trace and materializing
virtual tables are internal providers.
In other words, high OLEDB waitstats are not very often a problem.
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2005 All rights reserved.
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:4utf015ilc6kaha46e8c5pme6972q7gdo7@.4ax.com...
> If you query master..sysprocesses, you can get the spids,
> wait types and wait times.
> If you want to see what the spids are actually executing,
> pre-SP3, you can use:
> dbcc inputbuffer(spid)
> If you are on SP3, you can use:
> declare @.Handle binary(20)
> select @.Handle = sql_handle
> from sysprocesses
> where spid = <spid>
> select * from ::fn_get_sql(@.Handle)
> -Sue
> On Mon, 7 Feb 2005 14:51:02 -0800, Ken
> <Ken@.discussions.microsoft.com> wrote:
>

oledb wait type

We have a production server that's cpu is throttled, and requests are timing
out. After running the get_waitstats sp, OLEDB is at the top of the list in
wait type (99%).
How do I determine which spid is involved in an oledb wait type?
This is a Windows 2000 sp 3 box, running sql 2000.If you query master..sysprocesses, you can get the spids,
wait types and wait times.
If you want to see what the spids are actually executing,
pre-SP3, you can use:
dbcc inputbuffer(spid)
If you are on SP3, you can use:
declare @.Handle binary(20)
select @.Handle = sql_handle
from sysprocesses
where spid = <spid>
select * from ::fn_get_sql(@.Handle)
-Sue
On Mon, 7 Feb 2005 14:51:02 -0800, Ken
<Ken@.discussions.microsoft.com> wrote:

>We have a production server that's cpu is throttled, and requests are timin
g
>out. After running the get_waitstats sp, OLEDB is at the top of the list in
>wait type (99%).
>How do I determine which spid is involved in an oledb wait type?
>This is a Windows 2000 sp 3 box, running sql 2000.
>|||OLEDB waittype is an overloaded waittype to begin with, it is set for:
* linked server calls
* bulk insert
* running SQL Trace
* running 6.x to 7.0 or 2000 conversion imports
* materializing virtual tables like select * from master.dbo.sysprocesses
and select * from master.dbo.syslockinfo
Also this wait state is set differently, since it is set when the call is
entered and unset when the call is done, so when you start a BULK INSERT it
will be set, when you are done it is unset, bt you are not really waiting,
you are doing real work, only inside an OLE DB provider, for example BULK
INSERT is hosted in the IMPROV.DLL provider, SQL Trace and materializing
virtual tables are internal providers.
In other words, high OLEDB waitstats are not very often a problem.
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright SQLDev.Net 1991-2005 All rights reserved.
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:4utf015ilc6kaha46e8c5pme6972q7gdo7@.
4ax.com...
> If you query master..sysprocesses, you can get the spids,
> wait types and wait times.
> If you want to see what the spids are actually executing,
> pre-SP3, you can use:
> dbcc inputbuffer(spid)
> If you are on SP3, you can use:
> declare @.Handle binary(20)
> select @.Handle = sql_handle
> from sysprocesses
> where spid = <spid>
> select * from ::fn_get_sql(@.Handle)
> -Sue
> On Mon, 7 Feb 2005 14:51:02 -0800, Ken
> <Ken@.discussions.microsoft.com> wrote:
>
>

OLE DB Command Stage: Capturing Rejects

Hello group, I have a question regarding the OLE DB Command Stage. Currently, I am reviewing a Data Flow that runs in production. This Data Flow Inserts to the various dimension tables in our warehouse. For a particular dimension table, the flow is like this:

Read Source records for Product combinations LookUp Product combinations against the current dimProduct table (cached in memory) Rows not found are then subjected to another LookUp on the dimProduct table (not cached). This is to find any rows inserted during the current run Rows not found are then Inserted to dimProduct using a Stored Procedure invoked by an OLE DB Command Successful Inserts then continue on, Rejected Inserts should be captured to a Flat File on our server for review.

Apparently, this last step has never been successful at capturing Rejects. Obviously, we would want to review these records to find the reason for failure. We get an empty file.

Currently, in the Stored Procedure we are using logic like this:

IF @.PRODUCTCOUNT <> 0

BEGIN

RAISERROR ('DUPLICATE PRODUCT!', 10, 1)

RETURN

END

Questions:

Is the RAISERROR command going to give us Output? Can we implement the OUTPUT command in our Proc invocation? I have not found any documentation that says the OLE DB Command Stage supports Error logging (Although columns are available to be added in the Input/Output columns tab?) Should we be using another Stage to accomplish this?

Any thoughts are welcome, thanks for your time!

rg

IF @.PRODUCTCOUNT <> 0

BEGIN

RAISERROR ('DUPLICATE PRODUCT!', 10, 1)

RETURN

END

In my experience, the error disposition on the OLE DB Command does not work. At least I haven't been able to get it to work. It will ignore RAISERROR statements, yet fail the component on a divide by zero, but never redirect a row. Even if the error redirection did work, you wouldn't be able to get the error description you're trying to raise.

Happily, output parameters DO work (which still surprises me since it isn't documented and isn't really intuitive). I recommend you use an output parameter for the error description, assign it to a column in the data flow, and put a Conditional Split right after the OLE DB Command evaluating the column to roll your own error redirection.

|||

Jay, thanks for the tip. The research was leading me in the direction that the error disposition was less than robust. Thanks for the confirmation, I will pursue using OUTPUT parameters for this data flow.

Thanks for the help! I have much more experience with a different ETL toolset, so even the little things right now are a challenge.