Showing posts with label greetings. Show all posts
Showing posts with label greetings. Show all posts

Wednesday, March 28, 2012

NoRows SubReport

Greetings,

I have a report which contains three subreports. Each subreport is contained within a rectangle in the main report so I can force a page break after each subreport. In each of the subreports, there is a graphic and a text box on one line, then another text box below those two items, then a table below all that. My problem is that if one of the subreports returns no data, it is resulting in a NoRows sort of situation and not even the graphic and the two text boxes are shown. I understand that you can set a NoRows message, but ideally, I want my NoRows message to be the graphic and the two text boxes, not a plain text message.

I'm not sure if this is even possible or at the very least if I could conditionally force a page break in my rectangles based on whether one of the subreports returns a NoRows situation.

Thanks In Advance

One thing that you can do is create a second dataset that always returns data. You can do this with a query like the following. This causes the SubReport to always report to the processing runtime that it contains data, so that it should always be processed and rendered.

Select 1 as DataValue

However, the problem with this is that the empty table will still contain the Table headers. So, you will have to make the table conditionally visible using an expression such as this.

=IsNothing(Fields!FieldName.Value)

You can pretty much use any field in the dataset to which the table is bound.

Adding the second dataset and adding the conditional visibility to the table should result in the subreport still being displayed, with the table hidden.

Ian|||

This works perfectly. Thank You. In fact, due to the NoRows parameter being set on the subreport, the table headers themselves are not shown, but instead the NoRows message is shown WITH the graphic and two text boxes. This is exactly the result I wanted.

Saturday, February 25, 2012

No Windows, Only SQL Server Authentication

Greetings,
I am unable to log onto the MS SQL Server 2000 using my Windows Login name
and Password from the MS command prompt program locally on a new test
installation Windows Enterprise Server 2003 system. However, if I use an
SQL Server Login and Password, it works every time. The command string I am
using is:
"osql.exe -S (local) -U login_name -P password"
When successful (SQL Authentication), an SQL command prompt is returned.
When unsuccessful (Windows Authentication), the following message is
received:
"Login failed for user login_name"
The SQL Server 2000 installation is enabled for both Windows and SQL
authentication and has been updated to the latest service packs.
The installation is a new test set up to experiment with Web Services using
MS SQL Server. The original problem was the installation of the
"wscrRecordStore" demonstration data base from the book, Programming
Microsoft .NET XML WEB SERVICES, by Foggon et al. However, the problem was
reduced to the simple command line issue above in order to troubleshoot it.
Since I am also the Windows and SQL Server system administrator, I have
tried a wide variety of different login strategies. Only users set up with
SQL Authentication seem to be able to access the SQL Server programatically.
What's the problem? This seems to be a straight forward but stubborn
failure.
Richard Scott
Critical Connections, Inc.To establish a Windows authenticated connection from OSQL, you need to
specify the -E parameter instead of -U and -P. This will use the account of
the currently logged in user. For example:
OSQL -S (local) -E

> Only users set up with SQL Authentication seem to be able to access the
SQL Server programatically.
Your connection string needs to specify the type of authentication desired.
Assuming you are using SqlClient:
Windows authentication:
Data Source=MyServer;Integrated Security=SSPI;Initial
Catalog=MyDatabase
SQL Server authentication:
Data Source=MyServer;User ID=MyLogin;Password=MyPassword;Initial
Catalog=MyDatabase
Also, see the article below for additional information on establishing a
trusted connection from ASP.NET:
http://support.microsoft.com/defaul...989&Product=sql
Hope this helps.
Dan Guzman
SQL Server MVP
"Richard Scott" <rtscott@.pacbell.net> wrote in message
news:6XL6c.12481$zh1.7776@.newssvr27.news.prodigy.com...
> Greetings,
> I am unable to log onto the MS SQL Server 2000 using my Windows Login name
> and Password from the MS command prompt program locally on a new test
> installation Windows Enterprise Server 2003 system. However, if I use an
> SQL Server Login and Password, it works every time. The command string I
am
> using is:
> "osql.exe -S (local) -U login_name -P password"
> When successful (SQL Authentication), an SQL command prompt is returned.
> When unsuccessful (Windows Authentication), the following message is
> received:
> "Login failed for user login_name"
> The SQL Server 2000 installation is enabled for both Windows and SQL
> authentication and has been updated to the latest service packs.
> The installation is a new test set up to experiment with Web Services
using
> MS SQL Server. The original problem was the installation of the
> "wscrRecordStore" demonstration data base from the book, Programming
> Microsoft .NET XML WEB SERVICES, by Foggon et al. However, the problem
was
> reduced to the simple command line issue above in order to troubleshoot
it.
> Since I am also the Windows and SQL Server system administrator, I have
> tried a wide variety of different login strategies. Only users set up
with
> SQL Authentication seem to be able to access the SQL Server
programatically.
> What's the problem? This seems to be a straight forward but stubborn
> failure.
> Richard Scott
> Critical Connections, Inc.
>|||Not sure if this applies to you, but vefiry that the user who is attempting
to connect actually has a login established in SQL Server. You can do this
by expanding the Security folder in Enterprise Manager and looking at the
Logins.
Rand
This posting is provided "as is" with no warranties and confers no rights.