Hi,
Why new SS2005 doesn't see mapped drives anymore?
I use SS2005, SP1
Thanks in advance
Nikola MilicNikola Milic wrote:
> Hi,
> Why new SS2005 doesn't see mapped drives anymore?
> I use SS2005, SP1
> Thanks in advance
> Nikola Milic
>
>
Hi
I don't know if there're any difference in this compared to SS2000, but
the question is why do you want to see/use mapped drives? It's
recommenced to use UNC path rather than mapped drives.
Regards
Steen Schlüter Persson
Databaseadministrator / Systemadministrator|||Steen Persson (DK) wrote:
> Nikola Milic wrote:
> > Hi,
> > Why new SS2005 doesn't see mapped drives anymore?
> >
> > I use SS2005, SP1
> >
> > Thanks in advance
> > Nikola Milic
> >
> >
> >
> Hi
> I don't know if there're any difference in this compared to SS2000, but
> the question is why do you want to see/use mapped drives? It's
> recommenced to use UNC path rather than mapped drives.
>
> --
> Regards
> Steen Schl=FCter Persson
> Databaseadministrator / Systemadministrator
If you mapp drives in SQL Server through xp_cmdshell using net use SQL
Server can see it.
Regards
Amish Shah|||Hi,
Take a look int below URL.
http://support.microsoft.com/default.aspx?scid=kb;en-us;304261
Thanks
Hari
SQL Server MVP
"Nikola Milic" <hotmnikola@.hotmail.com> wrote in message
news:OXpZooK0GHA.3440@.TK2MSFTNGP06.phx.gbl...
> Hi,
> Why new SS2005 doesn't see mapped drives anymore?
> I use SS2005, SP1
> Thanks in advance
> Nikola Milic
>|||Nikola Milic wrote:
> Hi,
> Why new SS2005 doesn't see mapped drives anymore?
> I use SS2005, SP1
> Thanks in advance
> Nikola Milic
>
The drive mappings must be created under within the profile of the user
that the SQL Server service is running under. In other words, if SQL is
running as "DOMAIN\SQLServiceUser", and you create the drive mappings
while logged in as "DOMAIN\MyPersonalUser", the mappings won't be usable
by SQL.
As Steen indicated, it is preferred and advised to use UNC path names,
and not drive mappings.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Thank you all for help
And special thanks to Amish - that is what I wanted.
Nikola
"amish" <shahamishm@.gmail.com> wrote in message
news:1157450921.948672.98340@.h48g2000cwc.googlegroups.com...
If you mapp drives in SQL Server through xp_cmdshell using net use SQL
Server can see it.
Regards
Amish Shah
Showing posts with label sp1. Show all posts
Showing posts with label sp1. Show all posts
Wednesday, March 28, 2012
Monday, March 26, 2012
Many-to-many dimension processing performance
Hello,
I have a problem regarding M2M dimension processing performance that I would like some help with please.
We are using SSAS 2005 SP1 Entreprise Edition x64 bit
The main fact table has over a 100 milliion rows.
The entire SSAS database, both dims and facts, are MOLAP.
We have several many-to-many (M2M) dimensions connected to the main fact table via an intermediate measure group (IMG).
The M2M dim and the IMG are using the same database object as their source and are thus linked as fact relationship. This shared object is a 'normal' view not a table or indexed view.
We need to be able to process the M2M dim on a regular basis as user defined members change - sometimes every few minutes.
To do this we need to
1. Process Update the M2M dim
2. Full (or incremental) process the IMG
3. Process Indexes on the main fact
Steps 1 and 2 seem quite quick and arent currently thought to be a problem
Step 3, index processing, is taking too long, a few minutes or more, which our user base wont accept - we need to reduce this time.
Question
-
How can we reduce the time to process the indexes? Can we remove this step altogether in some way? Are there properties I can set to remove the process index necessity?
Please help if you can
--
Thanks in advance
Mgale1
You can try and skip step 3 all together and enable Lazy processing. This allows you to let users query the cube right after step 2. Analysis Server will be processing indexes in the background for you while users query.
This has obvious peroformance impact on the cube, users will be getting slower performance while indexes are not there and lazy processing is still going.
Another way to minimize time for building indexes is to patition you cube and let build index for several partitions to run in parallel. This should shorten processing times.
Edward Melomed.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
|||
Edward,
Lazy Processing is enabled on the server; it is the default.setting.I have also noticed that each fact or dim has a 'processing mode' available from the properties window.
I am confused as to where I should set this.
Do I need to set it on the M2M dimension, the Intermediate Measue Group, the 'local' dimension or the main fact table?
Please help if you can
Thanks
Mgale1
As far as I understand the main time in your schenario goes for processing indexes for the partitions in the main fact measure group. These partitions the candidates for setting processing mode to LazyAggregations.
The rest of the objects should be relatively fast to process.
Edward Melomed.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Monday, March 12, 2012
Manipulating parameters passed into a report - errors with parameters
Hi,
I've discovered a problem with repserv sp1 that I just can't see a way
around at the moment.
Basically we have a custom front end that allows the user to select
the params from either dropdown controls or textboxes. The text boxes
allow four states:
1/ All records
2/ Exact match
3/ Partial Match
4/ Starts with
The partial match is causing me the problem. Basically in the code
behind i'm prepending/appending the like clause character % to the
contents of the textbox i.e.
user enters 0123 into the textbox, the param passed into the report is
%0123%
Thats where the problem lies, repserv doesnt seem to accept that as a
valid param. It doesnt give any errors but it doesnt display the
required resultset. In the params returned to the user on the report,
it shows
23% has been passed in. The same thing happens if I type the url in
manually i.e.
http://localhost/Reportserver/MyReports/ListReport&rs:Command=Render&rs:Format=HTML4.0&rc:parameters=false&NameRefValue=%0123%&NameRefType=3
NameRefValue is declared as a string param, NameRefType is declared as
an integer param
Anyone have any ideas on this? Is it possible to manipulate the params
passed into the report before the engine actually processes them? If
this is possible I could just pass in the string without the %
characters & based on NamRefType value, add the % in the report itself
before the dataset is returned.
Cheers
SiSi wrote:
> Hi,
> I've discovered a problem with repserv sp1 that I just can't see a way
> around at the moment.
> Basically we have a custom front end that allows the user to select
> the params from either dropdown controls or textboxes. The text boxes
> allow four states:
> 1/ All records
> 2/ Exact match
> 3/ Partial Match
> 4/ Starts with
> The partial match is causing me the problem. Basically in the code
> behind i'm prepending/appending the like clause character % to the
> contents of the textbox i.e.
> user enters 0123 into the textbox, the param passed into the report is
> %0123%
>
Just read this the other day:
"NOTE Wildcards in Your SQL The filters you specify for your reports
are based on Visual Basic .Net 2003 syntax, so you'll find that the
pattern matching with the Like operator uses * as a wildcard and not %,
as you might use in SQL Like expressions."
_Hitchhiker's Guide to SQL Server 2000 Reporting Services_ by Peter
Blackburn and William R. Vaughan, Addison-Wesley 2005, p. 272.
hth
--Mike|||Thanks Mike,
I've just tried it and although the strange corruption of the
parameter is now ok, I still get incorrect results returned.
I use the % syntax in the starting with section with no problems, it
just seems to fail on integers and partial matches
Cheers anyway, it gave me a couple of ideas there!
Si
On Mon, 14 Feb 2005 07:54:53 -0600, "Mike Donnellan"
<spamspamspamandspam@.AT@.donnellanDOTcom> wrote:
>Just read this the other day:
>"NOTE Wildcards in Your SQL The filters you specify for your reports
>are based on Visual Basic .Net 2003 syntax, so you'll find that the
>pattern matching with the Like operator uses * as a wildcard and not %,
>as you might use in SQL Like expressions."
>_Hitchhiker's Guide to SQL Server 2000 Reporting Services_ by Peter
>Blackburn and William R. Vaughan, Addison-Wesley 2005, p. 272.
>hth
>--Mike|||Percent character is used to URL encode/escape other characters, so it
should itself also be encoded.
Check if this url works:
http://localhost/Reportserver/MyReports/ListReport&rs:Command=Render&rs:Format=HTML4.0&rc:parameters=false&NameRefValue=%250123%25&NameRefType=3
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Si" <no@.spam.thanks> wrote in message
news:mn4111pcl3qv3p6803i6pbstmhpch4lcge@.4ax.com...
> Hi,
> I've discovered a problem with repserv sp1 that I just can't see a way
> around at the moment.
> Basically we have a custom front end that allows the user to select
> the params from either dropdown controls or textboxes. The text boxes
> allow four states:
> 1/ All records
> 2/ Exact match
> 3/ Partial Match
> 4/ Starts with
> The partial match is causing me the problem. Basically in the code
> behind i'm prepending/appending the like clause character % to the
> contents of the textbox i.e.
> user enters 0123 into the textbox, the param passed into the report is
> %0123%
> Thats where the problem lies, repserv doesnt seem to accept that as a
> valid param. It doesnt give any errors but it doesnt display the
> required resultset. In the params returned to the user on the report,
> it shows
> 23% has been passed in. The same thing happens if I type the url in
> manually i.e.
> http://localhost/Reportserver/MyReports/ListReport&rs:Command=Render&rs:Format=HTML4.0&rc:parameters=false&NameRefValue=%0123%&NameRefType=3
> NameRefValue is declared as a string param, NameRefType is declared as
> an integer param
> Anyone have any ideas on this? Is it possible to manipulate the params
> passed into the report before the engine actually processes them? If
> this is possible I could just pass in the string without the %
> characters & based on NamRefType value, add the % in the report itself
> before the dataset is returned.
> Cheers
> Si|||Thanks Lev,
Yes that does seem to work ok. IS there a specific way I should be
encoding these characters or simply replace % with %25 ?
Cheers
Si
On Mon, 14 Feb 2005 21:16:54 -0800, "Lev Semenets [MSFT]"
<levs@.microsoft.com> wrote:
>Percent character is used to URL encode/escape other characters, so it
>should itself also be encoded.
>Check if this url works:
>http://localhost/Reportserver/MyReports/ListReport&rs:Command=Render&rs:Format=HTML4.0&rc:parameters=false&NameRefValue=%250123%25&NameRefType=3|||As a rule, I always try to limit query-string parameter values to the
actual value, and do formatting elsewhere.
Instead of passing the value %0123% via the query-string, why don't you
just pass the 0123 and add the "%" characters via an expression within
the RDL. This should completely avoid the problem you encountered with
encoding.
~Lance
http://weblogs.asp.net/lhunt/|||Thanks Lance,
Thats what I originally wanted to do but was unsure as to how to
manipulate the parameters before passing through to the stored proc.
In the end i've passed it all through as you say but direct to the
stored proc for processing & it now works fine.
I'd still be interested to know how to do it the way you mention.
Regards
Si
On 15 Feb 2005 07:02:36 -0800, "Lance" <lancehunt@.gmail.com> wrote:
>As a rule, I always try to limit query-string parameter values to the
>actual value, and do formatting elsewhere.
>Instead of passing the value %0123% via the query-string, why don't you
>just pass the 0123 and add the "%" characters via an expression within
>the RDL. This should completely avoid the problem you encountered with
>encoding.
>~Lance
>http://weblogs.asp.net/lhunt/|||I would normally recommend using the exact solution you chose, except I
wasnt sure if you were using a StoredProcedure or SQL. You definitely
should stick with your current implementation.
However, there are some cases where you can't use Stored Procedures,
such as with many ODBC connections to legacy systems. In such cases, I
recommend dynamically building your value for the LIKE expression in
the RDL.
Here are the basic steps:
1. Open "Data" tab from designer.
2. Select your DataSet from dropdown
3. Click on the "..." to go to properties.
4. Click on the Parameters tab
5. Locate the parameter in question
6. Modify the parameter value (right hand column) to use an expression.
7. Use the expression:
"="%" & Parameters!MyParam.Value & "%"
Instead of the default expression
"=Parameters!MyParam.Value"
8. Close Properties and you're ready to go!
Enjoy!
Lance Hunt
http://weblogs.asp.net/lhunt/
I've discovered a problem with repserv sp1 that I just can't see a way
around at the moment.
Basically we have a custom front end that allows the user to select
the params from either dropdown controls or textboxes. The text boxes
allow four states:
1/ All records
2/ Exact match
3/ Partial Match
4/ Starts with
The partial match is causing me the problem. Basically in the code
behind i'm prepending/appending the like clause character % to the
contents of the textbox i.e.
user enters 0123 into the textbox, the param passed into the report is
%0123%
Thats where the problem lies, repserv doesnt seem to accept that as a
valid param. It doesnt give any errors but it doesnt display the
required resultset. In the params returned to the user on the report,
it shows
23% has been passed in. The same thing happens if I type the url in
manually i.e.
http://localhost/Reportserver/MyReports/ListReport&rs:Command=Render&rs:Format=HTML4.0&rc:parameters=false&NameRefValue=%0123%&NameRefType=3
NameRefValue is declared as a string param, NameRefType is declared as
an integer param
Anyone have any ideas on this? Is it possible to manipulate the params
passed into the report before the engine actually processes them? If
this is possible I could just pass in the string without the %
characters & based on NamRefType value, add the % in the report itself
before the dataset is returned.
Cheers
SiSi wrote:
> Hi,
> I've discovered a problem with repserv sp1 that I just can't see a way
> around at the moment.
> Basically we have a custom front end that allows the user to select
> the params from either dropdown controls or textboxes. The text boxes
> allow four states:
> 1/ All records
> 2/ Exact match
> 3/ Partial Match
> 4/ Starts with
> The partial match is causing me the problem. Basically in the code
> behind i'm prepending/appending the like clause character % to the
> contents of the textbox i.e.
> user enters 0123 into the textbox, the param passed into the report is
> %0123%
>
Just read this the other day:
"NOTE Wildcards in Your SQL The filters you specify for your reports
are based on Visual Basic .Net 2003 syntax, so you'll find that the
pattern matching with the Like operator uses * as a wildcard and not %,
as you might use in SQL Like expressions."
_Hitchhiker's Guide to SQL Server 2000 Reporting Services_ by Peter
Blackburn and William R. Vaughan, Addison-Wesley 2005, p. 272.
hth
--Mike|||Thanks Mike,
I've just tried it and although the strange corruption of the
parameter is now ok, I still get incorrect results returned.
I use the % syntax in the starting with section with no problems, it
just seems to fail on integers and partial matches
Cheers anyway, it gave me a couple of ideas there!
Si
On Mon, 14 Feb 2005 07:54:53 -0600, "Mike Donnellan"
<spamspamspamandspam@.AT@.donnellanDOTcom> wrote:
>Just read this the other day:
>"NOTE Wildcards in Your SQL The filters you specify for your reports
>are based on Visual Basic .Net 2003 syntax, so you'll find that the
>pattern matching with the Like operator uses * as a wildcard and not %,
>as you might use in SQL Like expressions."
>_Hitchhiker's Guide to SQL Server 2000 Reporting Services_ by Peter
>Blackburn and William R. Vaughan, Addison-Wesley 2005, p. 272.
>hth
>--Mike|||Percent character is used to URL encode/escape other characters, so it
should itself also be encoded.
Check if this url works:
http://localhost/Reportserver/MyReports/ListReport&rs:Command=Render&rs:Format=HTML4.0&rc:parameters=false&NameRefValue=%250123%25&NameRefType=3
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Si" <no@.spam.thanks> wrote in message
news:mn4111pcl3qv3p6803i6pbstmhpch4lcge@.4ax.com...
> Hi,
> I've discovered a problem with repserv sp1 that I just can't see a way
> around at the moment.
> Basically we have a custom front end that allows the user to select
> the params from either dropdown controls or textboxes. The text boxes
> allow four states:
> 1/ All records
> 2/ Exact match
> 3/ Partial Match
> 4/ Starts with
> The partial match is causing me the problem. Basically in the code
> behind i'm prepending/appending the like clause character % to the
> contents of the textbox i.e.
> user enters 0123 into the textbox, the param passed into the report is
> %0123%
> Thats where the problem lies, repserv doesnt seem to accept that as a
> valid param. It doesnt give any errors but it doesnt display the
> required resultset. In the params returned to the user on the report,
> it shows
> 23% has been passed in. The same thing happens if I type the url in
> manually i.e.
> http://localhost/Reportserver/MyReports/ListReport&rs:Command=Render&rs:Format=HTML4.0&rc:parameters=false&NameRefValue=%0123%&NameRefType=3
> NameRefValue is declared as a string param, NameRefType is declared as
> an integer param
> Anyone have any ideas on this? Is it possible to manipulate the params
> passed into the report before the engine actually processes them? If
> this is possible I could just pass in the string without the %
> characters & based on NamRefType value, add the % in the report itself
> before the dataset is returned.
> Cheers
> Si|||Thanks Lev,
Yes that does seem to work ok. IS there a specific way I should be
encoding these characters or simply replace % with %25 ?
Cheers
Si
On Mon, 14 Feb 2005 21:16:54 -0800, "Lev Semenets [MSFT]"
<levs@.microsoft.com> wrote:
>Percent character is used to URL encode/escape other characters, so it
>should itself also be encoded.
>Check if this url works:
>http://localhost/Reportserver/MyReports/ListReport&rs:Command=Render&rs:Format=HTML4.0&rc:parameters=false&NameRefValue=%250123%25&NameRefType=3|||As a rule, I always try to limit query-string parameter values to the
actual value, and do formatting elsewhere.
Instead of passing the value %0123% via the query-string, why don't you
just pass the 0123 and add the "%" characters via an expression within
the RDL. This should completely avoid the problem you encountered with
encoding.
~Lance
http://weblogs.asp.net/lhunt/|||Thanks Lance,
Thats what I originally wanted to do but was unsure as to how to
manipulate the parameters before passing through to the stored proc.
In the end i've passed it all through as you say but direct to the
stored proc for processing & it now works fine.
I'd still be interested to know how to do it the way you mention.
Regards
Si
On 15 Feb 2005 07:02:36 -0800, "Lance" <lancehunt@.gmail.com> wrote:
>As a rule, I always try to limit query-string parameter values to the
>actual value, and do formatting elsewhere.
>Instead of passing the value %0123% via the query-string, why don't you
>just pass the 0123 and add the "%" characters via an expression within
>the RDL. This should completely avoid the problem you encountered with
>encoding.
>~Lance
>http://weblogs.asp.net/lhunt/|||I would normally recommend using the exact solution you chose, except I
wasnt sure if you were using a StoredProcedure or SQL. You definitely
should stick with your current implementation.
However, there are some cases where you can't use Stored Procedures,
such as with many ODBC connections to legacy systems. In such cases, I
recommend dynamically building your value for the LIKE expression in
the RDL.
Here are the basic steps:
1. Open "Data" tab from designer.
2. Select your DataSet from dropdown
3. Click on the "..." to go to properties.
4. Click on the Parameters tab
5. Locate the parameter in question
6. Modify the parameter value (right hand column) to use an expression.
7. Use the expression:
"="%" & Parameters!MyParam.Value & "%"
Instead of the default expression
"=Parameters!MyParam.Value"
8. Close Properties and you're ready to go!
Enjoy!
Lance Hunt
http://weblogs.asp.net/lhunt/
Monday, February 20, 2012
Management Studio Very slow to open
Hi,
I've had this problem with a VM and now on the Live box. I installed Windows Server 2003 SP1, then install SQL server 2005 and applied service pack 1.
As an administrator Management Studio takes approximately 2 seconds to open. However, if I log in to windows with any other local user account Manangement Studio takes approximately 1.5 minutes to open.
The whole interface is slow unless I use the administrator account to log into windows.
If anyone has a solution I would be very greatful as this is a new build for our production environment.
Thanks in advance.
Iain
Not sure if this will help, but if you have a look at internet explorer, on tools, internet options, advanced, security, check for publishers certificate revocation. I believe the default is enabled (ticked). On out NON-INTERNET facing DB machines, we have disabled that, and see a significant improvement in SSMS 'opening' time. I have heard that SSMS 'calls home' to check soemthing, and that by disabling this option, it no longer does this.
As I have it, the reason it can take so long is that on a non-internet facing machine, it waits for a timeout there.... true or not true ? I'm not sure, but I do know we are seeing a significant improvement
|||https://blogs.msdn.com/euanga/archive/2006/07/11/662053.aspx
|||Thanks very much for post. I'm teaching it on XPsp2 machines and the timeout was about 10 mins. Very annoying and this fix sorted it straight away takes 1 second to open now. :)
Subscribe to:
Posts (Atom)