Accessing Data Pump Properties

As a relatively new DBA I have been trying to resolve a problem for our
development staff.
From a remote controlled server console, any data pump will open in < 1
minute. Attempting to use enterprise manager on a local desktop, pointing to
the same server, opening the same data pump as above will take 5 - 6 minutes.
Has anyone else seen this? If so, what is the resolution?
Thanks for any help provided!Do you happen to have ODBC tracing turned on at the local server? that
would do it.
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
""Lori Andrasko via SQLMonster.com"" <forum@.SQLMonster.com> wrote in message
news:50ED31035DC30@.SQLMonster.com...
> As a relatively new DBA I have been trying to resolve a problem for our
> development staff.
> From a remote controlled server console, any data pump will open in < 1
> minute. Attempting to use enterprise manager on a local desktop, pointing
> to
> the same server, opening the same data pump as above will take 5 - 6
> minutes.
> Has anyone else seen this? If so, what is the resolution?
> Thanks for any help provided!

Accessing Data Pump Properties

As a relatively new DBA I have been trying to resolve a problem for our
development staff.
From a remote controlled server console, any data pump will open in < 1
minute. Attempting to use enterprise manager on a local desktop, pointing to
the same server, opening the same data pump as above will take 5 - 6 minutes.
Has anyone else seen this? If so, what is the resolution?
Thanks for any help provided!
Do you happen to have ODBC tracing turned on at the local server? that
would do it.
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
""Lori Andrasko via droptable.com"" <forum@.droptable.com> wrote in message
news:50ED31035DC30@.droptable.com...
> As a relatively new DBA I have been trying to resolve a problem for our
> development staff.
> From a remote controlled server console, any data pump will open in < 1
> minute. Attempting to use enterprise manager on a local desktop, pointing
> to
> the same server, opening the same data pump as above will take 5 - 6
> minutes.
> Has anyone else seen this? If so, what is the resolution?
> Thanks for any help provided!

Accessing Data Pump Properties

As a relatively new DBA I have been trying to resolve a problem for our
development staff.
From a remote controlled server console, any data pump will open in < 1
minute. Attempting to use enterprise manager on a local desktop, pointing t
o
the same server, opening the same data pump as above will take 5 - 6 minutes
.
Has anyone else seen this? If so, what is the resolution?
Thanks for any help provided!Do you happen to have ODBC tracing turned on at the local server? that
would do it.
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
""Lori Andrasko via droptable.com"" <forum@.droptable.com> wrote in message
news:50ED31035DC30@.droptable.com...
> As a relatively new DBA I have been trying to resolve a problem for our
> development staff.
> From a remote controlled server console, any data pump will open in < 1
> minute. Attempting to use enterprise manager on a local desktop, pointing
> to
> the same server, opening the same data pump as above will take 5 - 6
> minutes.
> Has anyone else seen this? If so, what is the resolution?
> Thanks for any help provided!

Access Report/Import Groupings

Hi Folks
Importing Access reports that have grouping are really quite a struggle.
All of the grouping sections are imported as controlled by report parameters.
Am I missing something, this is incredibly painfull with all of the build
errors in VS.NET?
RobI've reported this earlier, but the importation truely 'mangles' Access
Reports that are based on SQL Server sprocs that dynamically create record
sets (in my case dynamic creation of fields related to creating pivot tables
on the fly).
The issue is 'what does SSRS feel that it's important to do' in order to
retrieve a record set associated with a report.
The way to get ALL of this to work is a 3 step process:
1. Import the report from Access, which will give you a working sproc
dataset, but a mangle report import (that contains all kind of parameterized
stuff that SSRS couldn't figure out how to map).
2. Run the sproc standalone (in either Access or SQL Server) and create a
'working table' from the result set. Next, remap your Access query to this
'hard coded' table.
3. Finally, rerun the import on the remapped Access Report. The import is
almost correct (things like page breaks have to be redone and some other
little anomolies).
Delete the second dataset associated with 2nd import and delete the 1st
.rdl. This leaves you with a good dataset from the 1st import and a good
report from the 2nd import. Now just remap the dataset for the .rdl.
This is all because SSRS gets a little TOO carried away with trying to
interpret calls to sprocs (which use things like #tables and dynamically
define columns). This needs to be changed in the report creation and import
features of the product. This is TOO constraining to the point where the
product is making poor import decisions as well as being an absolute 'show
stopper' on new report creation where it uses a sproc.
Rob
"tutor" wrote:
> Hi Folks
> Importing Access reports that have grouping are really quite a struggle.
> All of the grouping sections are imported as controlled by report parameters.
> Am I missing something, this is incredibly painfull with all of the build
> errors in VS.NET?
> Rob