I have a report of Assets where I let the user decide if they want to group
on the Asset category or not. If they choose a Group from the Parameter
list, the report puts the Asset Category in the Group Header. If they choose
not to group, then it puts nothing in the Group Header. However, this leaves
a blank spot that doesn't look right. How can get rid of the Group Header if
the user selects '<None>' from the parameter list?
The first field in my Group Header looks like this:
=IIF(Parameters!GroupOn.Value = "Asset Category",
Fields!AssetCategory.Value, "")
--
Thank You!Hi,
Go to the parameters, in the visibility , click on the epression and type
the expression and it will hide accordingly.
OR right click the group,click edit group,click visibility and do the
expression there as well.
cheers
"Shane Eckel" wrote:
> I have a report of Assets where I let the user decide if they want to group
> on the Asset category or not. If they choose a Group from the Parameter
> list, the report puts the Asset Category in the Group Header. If they choose
> not to group, then it puts nothing in the Group Header. However, this leaves
> a blank spot that doesn't look right. How can get rid of the Group Header if
> the user selects '<None>' from the parameter list?
> The first field in my Group Header looks like this:
> =IIF(Parameters!GroupOn.Value = "Asset Category",
> Fields!AssetCategory.Value, "")
> --
> Thank You!|||Nice, I'll try this right now. Thanks for taking the time to reply to my
inquiry.
Take care,
Shane
"Bismi" wrote:
> Hi,
> Go to the parameters, in the visibility , click on the epression and type
> the expression and it will hide accordingly.
> OR right click the group,click edit group,click visibility and do the
> expression there as well.
> cheers
> "Shane Eckel" wrote:
> > I have a report of Assets where I let the user decide if they want to group
> > on the Asset category or not. If they choose a Group from the Parameter
> > list, the report puts the Asset Category in the Group Header. If they choose
> > not to group, then it puts nothing in the Group Header. However, this leaves
> > a blank spot that doesn't look right. How can get rid of the Group Header if
> > the user selects '<None>' from the parameter list?
> >
> > The first field in my Group Header looks like this:
> > =IIF(Parameters!GroupOn.Value = "Asset Category",
> > Fields!AssetCategory.Value, "")
> > --
> > Thank You!|||Thanks for posting this answer, but it isn't behaving correctly.
If I put the expression on the Edit Group level, the entire group hides.
If I put the expression on the textbox, the text within the field hides, but
the row does not shrink.
Any other ideas?
--
Thank You!
"Bismi" wrote:
> Hi,
> Go to the parameters, in the visibility , click on the epression and type
> the expression and it will hide accordingly.
> OR right click the group,click edit group,click visibility and do the
> expression there as well.
> cheers
> "Shane Eckel" wrote:
> > I have a report of Assets where I let the user decide if they want to group
> > on the Asset category or not. If they choose a Group from the Parameter
> > list, the report puts the Asset Category in the Group Header. If they choose
> > not to group, then it puts nothing in the Group Header. However, this leaves
> > a blank spot that doesn't look right. How can get rid of the Group Header if
> > the user selects '<None>' from the parameter list?
> >
> > The first field in my Group Header looks like this:
> > =IIF(Parameters!GroupOn.Value = "Asset Category",
> > Fields!AssetCategory.Value, "")
> > --
> > Thank You!
Showing posts with label group. Show all posts
Showing posts with label group. Show all posts
Thursday, March 8, 2012
Sunday, February 19, 2012
Changing Group BackgroundColor from Field Values
Hello Everybody,
I'am working with "Reporting Services 2005".
I would like to have specific Colors for a Group.
e.g.
+Apel: (Group, f.e. "green")
+peach: (Group, f.e. "red")
....
Apel and peach have each a color assigned in the database.
Each Report can have different Fruits on it, but they are defined by their color.
Could change the color statically and and toggle Details Colors, but nut this!
Thanks very much for any kind of help!
Have your query return the background color. THen add that color field to your group. Set the rowdetail background to the color from the dataset.|||Thanks very much, it works!Tuesday, February 14, 2012
Changing Default SQL ports on SQL 2000 Server
Hi Group,
As part of best practices we would like to change the default port number
that SQL Server 2000 listens on.
Once this has been done, can the application client dynamically determine
the new port number using the SQL Server Reporting Service listening on udp
1434?
Please note that Named Pipes are being used to establish the connections and
that there is a firewall between the SQL Server and the
applications clients.
Regards
CMHi,
Just change the port via the SQL Server Network Utility. On the client
open the Client Network Utility and create a TCP/IP based alias that
dynamically determines the port. The client will then use port 1434 to
determine which port it needs to use. Make sure that your firewall has
both port 1434 and the port the SQL Server instance is listening on open.
Jonathan
CP wrote:
> Hi Group,
> As part of best practices we would like to change the default port number
> that SQL Server 2000 listens on.
> Once this has been done, can the application client dynamically determine
> the new port number using the SQL Server Reporting Service listening on ud
p
> 1434?
> Please note that Named Pipes are being used to establish the connections a
nd
> that there is a firewall between the SQL Server and the
> applications clients.
> Regards
> CM
>|||Hi Jonathan,
Thank you for your response. Can I still do this (creating the TCP/IP based)
if I am using Named Pipes as my connector on the client?
I have read a post somewhere that Named Pipes cannot dynamically determine
destination SQL port numbers in SQL Server 2000.
Regards
CM
"JPD" wrote:
> Hi,
> Just change the port via the SQL Server Network Utility. On the client
> open the Client Network Utility and create a TCP/IP based alias that
> dynamically determines the port. The client will then use port 1434 to
> determine which port it needs to use. Make sure that your firewall has
> both port 1434 and the port the SQL Server instance is listening on open.
> Jonathan
>
> CP wrote:
>|||Hi,
In your case you need to do nothing on the clients. Named Pipes on the
client will be able to negotiate a connection with the server.
Jonathan
CP wrote:[vbcol=seagreen]
> Hi Jonathan,
> Thank you for your response. Can I still do this (creating the TCP/IP base
d)
> if I am using Named Pipes as my connector on the client?
> I have read a post somewhere that Named Pipes cannot dynamically determine
> destination SQL port numbers in SQL Server 2000.
> Regards
> CM
> "JPD" wrote:
>|||Hi Jonathan,
Thank you again for your reply.
I am a bit confused here, as I had the understanding that Named Pipes and
TCP/IP were two different connectivity mechanisms and that if Named Pipes ar
e
used in SQL 2000, the connections will fail if the default port is changed a
s
Named Pipes in SQL 2000 cannot dynamically determine destination port number
s.
Regards
CM
"JPD" wrote:
> Hi,
> In your case you need to do nothing on the clients. Named Pipes on the
> client will be able to negotiate a connection with the server.
> Jonathan
>
>
> CP wrote:
>
As part of best practices we would like to change the default port number
that SQL Server 2000 listens on.
Once this has been done, can the application client dynamically determine
the new port number using the SQL Server Reporting Service listening on udp
1434?
Please note that Named Pipes are being used to establish the connections and
that there is a firewall between the SQL Server and the
applications clients.
Regards
CMHi,
Just change the port via the SQL Server Network Utility. On the client
open the Client Network Utility and create a TCP/IP based alias that
dynamically determines the port. The client will then use port 1434 to
determine which port it needs to use. Make sure that your firewall has
both port 1434 and the port the SQL Server instance is listening on open.
Jonathan
CP wrote:
> Hi Group,
> As part of best practices we would like to change the default port number
> that SQL Server 2000 listens on.
> Once this has been done, can the application client dynamically determine
> the new port number using the SQL Server Reporting Service listening on ud
p
> 1434?
> Please note that Named Pipes are being used to establish the connections a
nd
> that there is a firewall between the SQL Server and the
> applications clients.
> Regards
> CM
>|||Hi Jonathan,
Thank you for your response. Can I still do this (creating the TCP/IP based)
if I am using Named Pipes as my connector on the client?
I have read a post somewhere that Named Pipes cannot dynamically determine
destination SQL port numbers in SQL Server 2000.
Regards
CM
"JPD" wrote:
> Hi,
> Just change the port via the SQL Server Network Utility. On the client
> open the Client Network Utility and create a TCP/IP based alias that
> dynamically determines the port. The client will then use port 1434 to
> determine which port it needs to use. Make sure that your firewall has
> both port 1434 and the port the SQL Server instance is listening on open.
> Jonathan
>
> CP wrote:
>|||Hi,
In your case you need to do nothing on the clients. Named Pipes on the
client will be able to negotiate a connection with the server.
Jonathan
CP wrote:[vbcol=seagreen]
> Hi Jonathan,
> Thank you for your response. Can I still do this (creating the TCP/IP base
d)
> if I am using Named Pipes as my connector on the client?
> I have read a post somewhere that Named Pipes cannot dynamically determine
> destination SQL port numbers in SQL Server 2000.
> Regards
> CM
> "JPD" wrote:
>|||Hi Jonathan,
Thank you again for your reply.
I am a bit confused here, as I had the understanding that Named Pipes and
TCP/IP were two different connectivity mechanisms and that if Named Pipes ar
e
used in SQL 2000, the connections will fail if the default port is changed a
s
Named Pipes in SQL 2000 cannot dynamically determine destination port number
s.
Regards
CM
"JPD" wrote:
> Hi,
> In your case you need to do nothing on the clients. Named Pipes on the
> client will be able to negotiate a connection with the server.
> Jonathan
>
>
> CP wrote:
>
Subscribe to:
Posts (Atom)