How do I create a user, that has rights to only one database, and only
select rights to some views?
I created a login in Enterprise Manager; checked the database access only on
the database the user needs to see; and checked the db_datareader role.
However, logging in as this user I can see and select from other databases.
Under the database I gave the user rights to, I checked only select rights
on the views I want the user to select from. I can still select from
tables, etc.
Obviously, I'm missing something here...Which other databases? Most likely those are databases with
the guest account enabled. If a user doesn't have an account
to log into the database and the guest account is enabled,
the user has access through the guest account and whatever
rights are granted to public and this account. The guest
account cannot be deleted from master or tempdb. It can be
added, delete from other databases.
When you added the user to the db_datareader role, you gave
that user permissions to select from all user tables.
Permissions are cumulative so the user obtains all
permissions through the combination of their individual
account and any groups, roles that they are members of. When
you also gave the individual account select permission on
views, the user ended up with those permissions as well as
select on all user tables.
-Sue
On Thu, 28 Oct 2004 17:39:38 -0400, "Adrian Maull \(MCP\)"
<no_spam@.no_email.org> wrote:
>How do I create a user, that has rights to only one database, and only
>select rights to some views?
>I created a login in Enterprise Manager; checked the database access only o
n
>the database the user needs to see; and checked the db_datareader role.
>However, logging in as this user I can see and select from other databases.
>Under the database I gave the user rights to, I checked only select rights
>on the views I want the user to select from. I can still select from
>tables, etc.
>Obviously, I'm missing something here...
>|||sue i can't see guest account except master database.. you meant somebody
created it ?
"Sue Hoegemeier" wrote:
> Which other databases? Most likely those are databases with
> the guest account enabled. If a user doesn't have an account
> to log into the database and the guest account is enabled,
> the user has access through the guest account and whatever
> rights are granted to public and this account. The guest
> account cannot be deleted from master or tempdb. It can be
> added, delete from other databases.
> When you added the user to the db_datareader role, you gave
> that user permissions to select from all user tables.
> Permissions are cumulative so the user obtains all
> permissions through the combination of their individual
> account and any groups, roles that they are members of. When
> you also gave the individual account select permission on
> views, the user ended up with those permissions as well as
> select on all user tables.
> -Sue
> On Thu, 28 Oct 2004 17:39:38 -0400, "Adrian Maull \(MCP\)"
> <no_spam@.no_email.org> wrote:
>
>|||No...nothing about someone creating the guest account but I
don't know what databases the user is accessing. Which other
databases? System databases or user databases? Is the user a
member of other roles or groups that would give them access
to the other databases?
-Sue
On Thu, 28 Oct 2004 19:53:01 -0700, "Dave"
<Dave@.discussions.microsoft.com> wrote:
[vbcol=seagreen]
>sue i can't see guest account except master database.. you meant somebody
>created it ?
>"Sue Hoegemeier" wrote:
>|||I've deleted the guest account from other user DBs and the user I can not
see/connect to those DBs - good.
I've unchecked the db_datareader role and only gave select permissions to 2
views in the DB - that seems to work OK as well.
However, the user can still select from system tables in the database they
are assigned to. Any way to prevent that?
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:og93o0loelonsc0tkhbhau449s6defp78l@.
4ax.com...
> Which other databases? Most likely those are databases with
> the guest account enabled. If a user doesn't have an account
> to log into the database and the guest account is enabled,
> the user has access through the guest account and whatever
> rights are granted to public and this account. The guest
> account cannot be deleted from master or tempdb. It can be
> added, delete from other databases.
> When you added the user to the db_datareader role, you gave
> that user permissions to select from all user tables.
> Permissions are cumulative so the user obtains all
> permissions through the combination of their individual
> account and any groups, roles that they are members of. When
> you also gave the individual account select permission on
> views, the user ended up with those permissions as well as
> select on all user tables.
> -Sue|||The public role is able to select from some of the system tables. All
database user are members of public. That's why the user can select
from some of the system tables.
-Sue
On Fri, 29 Oct 2004 08:55:09 -0400, "Adrian Maull \(MCP\)"
<no_spam@.no_email.org> wrote:
>I've deleted the guest account from other user DBs and the user I can not
>see/connect to those DBs - good.
>I've unchecked the db_datareader role and only gave select permissions to 2
>views in the DB - that seems to work OK as well.
>However, the user can still select from system tables in the database they
>are assigned to. Any way to prevent that?
>"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
> news:og93o0loelonsc0tkhbhau449s6defp78l@.
4ax.com...
>|||Adrian
In additon to Sue's advice ,if you don't want the users be able to select
from system tables , you can hide them by editing SQL Server registration
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:m745o01h1ck4l9e3262931g9nktach4ru3@.
4ax.com...
> The public role is able to select from some of the system tables. All
> database user are members of public. That's why the user can select
> from some of the system tables.
> -Sue
> On Fri, 29 Oct 2004 08:55:09 -0400, "Adrian Maull \(MCP\)"
> <no_spam@.no_email.org> wrote:
>
2[vbcol=seagreen]
they[vbcol=seagreen]
>|||That doesn't prevent users from being able to select from
system tables though. All that will do is prevent displaying
them in Enterprise Manager.
-Sue
On Sun, 31 Oct 2004 11:20:42 +0200, "Uri Dimant"
<urid@.iscar.co.il> wrote:
>Adrian
>In additon to Sue's advice ,if you don't want the users be able to select
>from system tables , you can hide them by editing SQL Server registration
>
>"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
> news:m745o01h1ck4l9e3262931g9nktach4ru3@.
4ax.com...
>2
>they
>|||Yep, I assumed that all manipulations are done by users in EM.
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:qi5bo0lo2223mjjdqcfkdlhvafhlg596i0@.
4ax.com...
> That doesn't prevent users from being able to select from
> system tables though. All that will do is prevent displaying
> them in Enterprise Manager.
> -Sue
> On Sun, 31 Oct 2004 11:20:42 +0200, "Uri Dimant"
> <urid@.iscar.co.il> wrote:
>
not[vbcol=seagreen]
to[vbcol=seagreen]
>|||I am trying to do the same thing. I have a user that needs access to one of
the databases on the server. I can prevent him from modifying or even seeing
the tables on the other databases with permissions, but I want to be able to
hide the other databases from Enterprise Manager. I am using SQL logins. Can
I do this? It sounds like you were able to do this. I have deleted the guest
account from a number of databases and added his login to only two databases
but the login displays all of the databases, including those with only sa as
the login.
"Adrian Maull (MCP)" wrote:
> I've deleted the guest account from other user DBs and the user I can not
> see/connect to those DBs - good.
> I've unchecked the db_datareader role and only gave select permissions to
2
> views in the DB - that seems to work OK as well.
> However, the user can still select from system tables in the database they
> are assigned to. Any way to prevent that?
> "Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
> news:og93o0loelonsc0tkhbhau449s6defp78l@.
4ax.com...
>
>
Showing posts with label enterprise. Show all posts
Showing posts with label enterprise. Show all posts
Monday, March 26, 2012
Friday, March 23, 2012
Read Failure General SQL Error
I am using Delphi 5 Enterprise version and SQL Server 2000. So, I use the
odbc bridge. SQL Client connects through TCP/IP(not named pipes). My
application works alright, but sometimes, the clients get this Error Read
Failure General SQL Error [Microsoft][ODBC SQL Server Driver]Communication
Link Failure. The client may works fine again for hours and again this
problems repeats. Please let me know of any solution. What should I do ?
"IGLC" <rightwayonline@.hotmaildot.com> wrote in message
news:OyrAX$lJGHA.1848@.TK2MSFTNGP12.phx.gbl...
>I am using Delphi 5 Enterprise version and SQL Server 2000. So,
>I use the
> odbc bridge. SQL Client connects through TCP/IP(not named
> pipes). My
> application works alright, but sometimes, the clients get this
> Error Read
> Failure General SQL Error [Microsoft][ODBC SQL Server
> Driver]Communication
> Link Failure. The client may works fine again for hours and
> again this
> problems repeats. Please let me know of any solution. What
> should I do ?
I think the error message says it all. The connection was
dropped.
- Arnie
|||OK, but why it was't happen befor.
and how to fix it.
|||"IGLC" <rightwayonline@.hotmaildot.com> wrote in message
news:OGYGOaoJGHA.1424@.TK2MSFTNGP12.phx.gbl...
> OK, but why it was't happen befor.
> and how to fix it.
>
It depends on the network to some extent. Connections should be
fairly solid on a LAN, server reboots aside. It would be more
likely to happen when using the internet and/or a VPN.
The error can be difficult to recover from. Certainly, the
SELECT (or whatever) should be in a try/catch block. You could
then catch the error, try a reconnect and retry the operation.
Not easy if you have a lot of DB I/O operations.
The only other thing I can think of is that SQL Server may have
an inactivity timeout. If this were the case, it might drop the
connection after some period of inactivity.
- Arnie
odbc bridge. SQL Client connects through TCP/IP(not named pipes). My
application works alright, but sometimes, the clients get this Error Read
Failure General SQL Error [Microsoft][ODBC SQL Server Driver]Communication
Link Failure. The client may works fine again for hours and again this
problems repeats. Please let me know of any solution. What should I do ?
"IGLC" <rightwayonline@.hotmaildot.com> wrote in message
news:OyrAX$lJGHA.1848@.TK2MSFTNGP12.phx.gbl...
>I am using Delphi 5 Enterprise version and SQL Server 2000. So,
>I use the
> odbc bridge. SQL Client connects through TCP/IP(not named
> pipes). My
> application works alright, but sometimes, the clients get this
> Error Read
> Failure General SQL Error [Microsoft][ODBC SQL Server
> Driver]Communication
> Link Failure. The client may works fine again for hours and
> again this
> problems repeats. Please let me know of any solution. What
> should I do ?
I think the error message says it all. The connection was
dropped.
- Arnie
|||OK, but why it was't happen befor.
and how to fix it.
|||"IGLC" <rightwayonline@.hotmaildot.com> wrote in message
news:OGYGOaoJGHA.1424@.TK2MSFTNGP12.phx.gbl...
> OK, but why it was't happen befor.
> and how to fix it.
>
It depends on the network to some extent. Connections should be
fairly solid on a LAN, server reboots aside. It would be more
likely to happen when using the internet and/or a VPN.
The error can be difficult to recover from. Certainly, the
SELECT (or whatever) should be in a try/catch block. You could
then catch the error, try a reconnect and retry the operation.
Not easy if you have a lot of DB I/O operations.
The only other thing I can think of is that SQL Server may have
an inactivity timeout. If this were the case, it might drop the
connection after some period of inactivity.
- Arnie
Read Failure General SQL Error
I am using Delphi 5 Enterprise version and SQL Server 2000. So, I use the
odbc bridge. SQL Client connects through TCP/IP(not named pipes). My
application works alright, but sometimes, the clients get this Error Read
Failure General SQL Error [Microsoft][ODBC SQL Server Driver]Communi
cation
Link Failure. The client may works fine again for hours and again this
problems repeats. Please let me know of any solution. What should I do ?"IGLC" <rightwayonline@.hotmaildot.com> wrote in message
news:OyrAX$lJGHA.1848@.TK2MSFTNGP12.phx.gbl...
>I am using Delphi 5 Enterprise version and SQL Server 2000. So,
>I use the
> odbc bridge. SQL Client connects through TCP/IP(not named
> pipes). My
> application works alright, but sometimes, the clients get this
> Error Read
> Failure General SQL Error [Microsoft][ODBC SQL Server
> Driver]Communication
> Link Failure. The client may works fine again for hours and
> again this
> problems repeats. Please let me know of any solution. What
> should I do ?
I think the error message says it all. The connection was
dropped.
- Arnie|||OK, but why it was't happen befor.
and how to fix it.|||"IGLC" <rightwayonline@.hotmaildot.com> wrote in message
news:OGYGOaoJGHA.1424@.TK2MSFTNGP12.phx.gbl...
> OK, but why it was't happen befor.
> and how to fix it.
>
It depends on the network to some extent. Connections should be
fairly solid on a LAN, server reboots aside. It would be more
likely to happen when using the internet and/or a VPN.
The error can be difficult to recover from. Certainly, the
SELECT (or whatever) should be in a try/catch block. You could
then catch the error, try a reconnect and retry the operation.
Not easy if you have a lot of DB I/O operations.
The only other thing I can think of is that SQL Server may have
an inactivity timeout. If this were the case, it might drop the
connection after some period of inactivity.
- Arnie
odbc bridge. SQL Client connects through TCP/IP(not named pipes). My
application works alright, but sometimes, the clients get this Error Read
Failure General SQL Error [Microsoft][ODBC SQL Server Driver]Communi
cation
Link Failure. The client may works fine again for hours and again this
problems repeats. Please let me know of any solution. What should I do ?"IGLC" <rightwayonline@.hotmaildot.com> wrote in message
news:OyrAX$lJGHA.1848@.TK2MSFTNGP12.phx.gbl...
>I am using Delphi 5 Enterprise version and SQL Server 2000. So,
>I use the
> odbc bridge. SQL Client connects through TCP/IP(not named
> pipes). My
> application works alright, but sometimes, the clients get this
> Error Read
> Failure General SQL Error [Microsoft][ODBC SQL Server
> Driver]Communication
> Link Failure. The client may works fine again for hours and
> again this
> problems repeats. Please let me know of any solution. What
> should I do ?
I think the error message says it all. The connection was
dropped.
- Arnie|||OK, but why it was't happen befor.
and how to fix it.|||"IGLC" <rightwayonline@.hotmaildot.com> wrote in message
news:OGYGOaoJGHA.1424@.TK2MSFTNGP12.phx.gbl...
> OK, but why it was't happen befor.
> and how to fix it.
>
It depends on the network to some extent. Connections should be
fairly solid on a LAN, server reboots aside. It would be more
likely to happen when using the internet and/or a VPN.
The error can be difficult to recover from. Certainly, the
SELECT (or whatever) should be in a try/catch block. You could
then catch the error, try a reconnect and retry the operation.
Not easy if you have a lot of DB I/O operations.
The only other thing I can think of is that SQL Server may have
an inactivity timeout. If this were the case, it might drop the
connection after some period of inactivity.
- Arnie
Tuesday, March 20, 2012
RE: Creating A Duplicate Database Without Enterprise Manager
Hi There,
I was wondering if there was a simple way of create a duplicate of an entire database.
I often need to create a second copy of a database for development purposes. I have lost the use of Enterprise Manager which I can no longer simply script the database and then use dts to move the data across.
Is there a way of doing this in T-SQL?
Thanks
SteveTake a full backup and restore as a different name ... that should do it .. i think ... rather than going about it the other way round.|||You lost the use of Enterprise Manager?
HUH?|||I think they're an amputee|||Perhaps it was destroyed by a Klingon Manager?|||Or a Romulan cloaking device has been attached, so it's really there, he just can't see it ;-)|||Could have been an Organian illusion all along...
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=55463
I was wondering if there was a simple way of create a duplicate of an entire database.
I often need to create a second copy of a database for development purposes. I have lost the use of Enterprise Manager which I can no longer simply script the database and then use dts to move the data across.
Is there a way of doing this in T-SQL?
Thanks
SteveTake a full backup and restore as a different name ... that should do it .. i think ... rather than going about it the other way round.|||You lost the use of Enterprise Manager?
HUH?|||I think they're an amputee|||Perhaps it was destroyed by a Klingon Manager?|||Or a Romulan cloaking device has been attached, so it's really there, he just can't see it ;-)|||Could have been an Organian illusion all along...
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=55463
Monday, March 12, 2012
rdlc viewer issues
I've created a few reporting services local (Visual Studio) reports to see
if this is a viable enterprise reporting option. I'm having rather abysmal
experience with the report viewer.
I design my report in the designer and it looks great. I run the
application and view it on the screen and see
- The left edges of text in text boxes is "clipped", as if the text is
running outside the textbox margin or something
- Some textboxes have switched to multiline as if it isn't long enough to
display the contents, but the textbox isn't tall enough for that and what
displays is just gobbledy-gook.
If I switch the view to print layout mode the clipping is still there but
the textboxes now display the entire contents horizontally like they did in
the designer.
In any case, if I print the report from the viewer it comes out pretty much
like it looked in the designer.
So, to recap:
- Left edges of text boxes are clipped in the viewer
- Reports layout like I designed them when in print layout mode but not
otherwise
- Printed reports don't look like they do when viewed on the screen
I must be doing something horribly wrong or have a misunderstanding of the
paradigm, because in my mind this is ridiculous for a reporting tool to
behave this way. I understand the CanGrow property, but it only controls
vertical sizing and in order to preserve my report esthetics I would need it
to grow horizontally.Make sure you report items (Textboxes, Lines, Rectangles, etc) do not
overlap. This usually causes the report to behave oddly in HTML as it
cannot overlap html objects very well. Usually you can avoid
overlapping items by using a table for your data region, instead of the
freeform List. Also, check the padding of your textboxes, and increase
the padding if needed.
Textboxes do not grow horizontally as this is the layout of the report
and is the behavior by design. You should increase the width of your
textboxes to the max size that you can within your report layout for
the data that will be displayed in them. You can set the CanGrow
property to true, which basically allows the renderer to wrap the text
to another line(s), like you said, controlling vertical sizing.
A lot of times, the result you get from viewing the report in the
viewer in HTML will not be exactly the same as when printing or
exporting to PDF or TIFF. The latter are print layout formats, and
will render the reports slightly different, because their media is
paper. For example, if you report has a page footer, in HTML, the
footer will show immediately after last item on the page, even if the
item is in the "middle" of the page, because HTML does not have concept
of "page sizes". If you print it or export to PDF, you will notice
that the renderer places the page footer at the bottom of the paper
page.
Hope this helps you!
Regards,
Thiago Silva, MCAD.NET
On Nov 22, 7:22 am, "Daniel Billingsley"
<DanielBillings...@.newsgroup.nospam> wrote:
> I've created a few reporting services local (Visual Studio) reports to see
> if this is a viable enterprise reporting option. I'm having rather abysmal
> experience with the report viewer.
> I design my report in the designer and it looks great. I run the
> application and view it on the screen and see
> - The left edges of text in text boxes is "clipped", as if the text is
> running outside the textbox margin or something
> - Some textboxes have switched to multiline as if it isn't long enough to
> display the contents, but the textbox isn't tall enough for that and what
> displays is just gobbledy-gook.
> If I switch the view to print layout mode the clipping is still there but
> the textboxes now display the entire contents horizontally like they did in
> the designer.
> In any case, if I print the report from the viewer it comes out pretty much
> like it looked in the designer.
> So, to recap:
> - Left edges of text boxes are clipped in the viewer
> - Reports layout like I designed them when in print layout mode but not
> otherwise
> - Printed reports don't look like they do when viewed on the screen
> I must be doing something horribly wrong or have a misunderstanding of the
> paradigm, because in my mind this is ridiculous for a reporting tool to
> behave this way. I understand the CanGrow property, but it only controls
> vertical sizing and in order to preserve my report esthetics I would need it
> to grow horizontally.|||Well, I have to say I think not handling overlapping items is a ridiculous
limitation - one that surely has the graphics designers in the crowd
laughing their rears off. My use of it is not a list layout issue, it's a
graphic design issue, so using a table doesn't help. What I'm trying to
create is an effect similar to the windows forms GroupBox whereby there's a
box with a border that is interrupted for the "title" of the box.
Additionally, I'd like the title to be surrounded with a border itself.
This is not really all that complex graphically, so I think it's a rather
sever limitation that the rdlc report can't handle it.
Considering that increasing the width of the textbox doesn't really work.
The problem I'm trying to point out is that I can't predict what it will
look like at runtime while in the designer. And even if I put forth the
painful effort of making a change and then having to run the application to
see the results (another completely ridiculous limitation), the problem
still exists that it would look good in the view but when printed look like
I was an idiot because there'd be a bunch of whitespace in the end of the
box (border).
IMPORTANT NOTE - this is all really a problem with textboxes with borders in
general and really doesn't have anything to do with the fact that I am using
it in an overlapping way in this particular case.
I say again, for a report writer not to be able to predict the results, and
for the results to be that different between viewing and printing, is
unacceptable. Period. Yes, I would expect the differences in the way page
footers are handled because there are no "pages" in HTML. Of course it
would work that way. But not that the actual layout of the body of the
report would change so significantly.
I did not appreciate that the default for the viewer was an HTML view. This
seems like another case where the relationship to the SQL RS engine is a
liability.
"tafs7" <tsilva7@.gmail.com> wrote in message
news:1164347626.531755.16330@.l39g2000cwd.googlegroups.com...
> Make sure you report items (Textboxes, Lines, Rectangles, etc) do not
> overlap. This usually causes the report to behave oddly in HTML as it
> cannot overlap html objects very well. Usually you can avoid
> overlapping items by using a table for your data region, instead of the
> freeform List. Also, check the padding of your textboxes, and increase
> the padding if needed.
> Textboxes do not grow horizontally as this is the layout of the report
> and is the behavior by design. You should increase the width of your
> textboxes to the max size that you can within your report layout for
> the data that will be displayed in them. You can set the CanGrow
> property to true, which basically allows the renderer to wrap the text
> to another line(s), like you said, controlling vertical sizing.
> A lot of times, the result you get from viewing the report in the
> viewer in HTML will not be exactly the same as when printing or
> exporting to PDF or TIFF. The latter are print layout formats, and
> will render the reports slightly different, because their media is
> paper. For example, if you report has a page footer, in HTML, the
> footer will show immediately after last item on the page, even if the
> item is in the "middle" of the page, because HTML does not have concept
> of "page sizes". If you print it or export to PDF, you will notice
> that the renderer places the page footer at the bottom of the paper
> page.
> Hope this helps you!
> Regards,
> Thiago Silva, MCAD.NET
>
> On Nov 22, 7:22 am, "Daniel Billingsley"
> <DanielBillings...@.newsgroup.nospam> wrote:
>> I've created a few reporting services local (Visual Studio) reports to
>> see
>> if this is a viable enterprise reporting option. I'm having rather
>> abysmal
>> experience with the report viewer.
>> I design my report in the designer and it looks great. I run the
>> application and view it on the screen and see
>> - The left edges of text in text boxes is "clipped", as if the text is
>> running outside the textbox margin or something
>> - Some textboxes have switched to multiline as if it isn't long enough to
>> display the contents, but the textbox isn't tall enough for that and what
>> displays is just gobbledy-gook.
>> If I switch the view to print layout mode the clipping is still there but
>> the textboxes now display the entire contents horizontally like they did
>> in
>> the designer.
>> In any case, if I print the report from the viewer it comes out pretty
>> much
>> like it looked in the designer.
>> So, to recap:
>> - Left edges of text boxes are clipped in the viewer
>> - Reports layout like I designed them when in print layout mode but not
>> otherwise
>> - Printed reports don't look like they do when viewed on the screen
>> I must be doing something horribly wrong or have a misunderstanding of
>> the
>> paradigm, because in my mind this is ridiculous for a reporting tool to
>> behave this way. I understand the CanGrow property, but it only controls
>> vertical sizing and in order to preserve my report esthetics I would need
>> it
>> to grow horizontally.
>|||Hey, Daniel
Have you tried using a rectangle with borders, instead of a textbox as
the container? I don't think you'll get quite the same effect as the
GroupBox with the title, but at least your rectangle will serve as a
container for other items, and you can have a textbox on the inside of
this rectangle at the top left corner acting as the "title" (note the
"Parent" property in the property page of any textbox placed inside the
rectangle, and you should see the rectangle name)
There is really nothing that prevents you from overlapping items in a
report, however in this version of the product, it unfortunately
doesn't do well rendering overlaps in all renderers. This is mainly a
problem for the HTML rendering extension of the viewer. The same
report, when exported to PDF, will look perfect, though.
In the Visual Studio designer, when you preview a report that contains
overlapped items, you will get a warning in the output window but this
will not prevent you from running the report:
[rsOverlappingReportItems] The textbox 'textbox3' and the rectangle
'rectangle1' overlap. Overlapping report items are not supported in
all renderers.
Build complete -- 0 errors, 1 warnings
As far as the textbox stretching horizontally, it would make no sense
to allow for textboxes to do that because it could inherently stretch
the width of the report body and page width causing the report to print
extra pages just for the extra width, since the printed page size is a
property that is set in the report (e.g. 8.5x11in vs. 11x8.5in -
portrait or landscape letter).
Now, since you're using the RDLC format, I am assuming you have a
custom application that provides a UI to the user for selecting reports
and entering parameters (if required). If that's the case, then your
application is responsible for providing the data as well and then
handing that over to the ReportViewer control for rendering. As such,
there is no way to "preview" your report from the Visual Studio
designer, because it doesn't know where the data is coming from. I
would recommend developing your reports as regular RDL files to begin
with, so you can test on the VS designer. You can even preview it w/
the ReportViewer by right-clicking the report name in the Solution
Explorer and selecting "Run". This will spin off a separate process
with an external windows app hosting the ReportViewer (note that
because this is a windows app, it still won't render the actual HTML
results you'd get from Internet Explorer).
Once you're happy with the results, you can "doctor" your RDL file so
it becomes an RDLC (see http://www.gotreportviewer.com for more
details) that is usable by your custom application.
Hope this helps you.
If you need any references to help you further your skills in SSRS, I
would recommend reading some of the SSRS team blogs for tips:
All about the ReportViewer - http://www.gotreportviewer.com/
Brian Welcker - http://blogs.msdn.com/bwelcker
Chris Hays - http://blogs.msdn.com/ChrisHays/ <= Sleazy Hacks for SSRS
:)
Tudor's blog - http://blogs.msdn.com/tudortr/
Lukasz Pawlowski - http://blogs.msdn.com/lukaszp/
Bob Meyers- http://blogs.msdn.com/bobmeyers
Regards,
Thiago Silva, MCAD.NET
Daniel Billingsley wrote:
> Well, I have to say I think not handling overlapping items is a ridiculous
> limitation - one that surely has the graphics designers in the crowd
> laughing their rears off. My use of it is not a list layout issue, it's a
> graphic design issue, so using a table doesn't help. What I'm trying to
> create is an effect similar to the windows forms GroupBox whereby there's a
> box with a border that is interrupted for the "title" of the box.
> Additionally, I'd like the title to be surrounded with a border itself.
> This is not really all that complex graphically, so I think it's a rather
> sever limitation that the rdlc report can't handle it.
> Considering that increasing the width of the textbox doesn't really work.
> The problem I'm trying to point out is that I can't predict what it will
> look like at runtime while in the designer. And even if I put forth the
> painful effort of making a change and then having to run the application to
> see the results (another completely ridiculous limitation), the problem
> still exists that it would look good in the view but when printed look like
> I was an idiot because there'd be a bunch of whitespace in the end of the
> box (border).
> IMPORTANT NOTE - this is all really a problem with textboxes with borders in
> general and really doesn't have anything to do with the fact that I am using
> it in an overlapping way in this particular case.
> I say again, for a report writer not to be able to predict the results, and
> for the results to be that different between viewing and printing, is
> unacceptable. Period. Yes, I would expect the differences in the way page
> footers are handled because there are no "pages" in HTML. Of course it
> would work that way. But not that the actual layout of the body of the
> report would change so significantly.
> I did not appreciate that the default for the viewer was an HTML view. This
> seems like another case where the relationship to the SQL RS engine is a
> liability.
> "tafs7" <tsilva7@.gmail.com> wrote in message
> news:1164347626.531755.16330@.l39g2000cwd.googlegroups.com...
> >
> > Make sure you report items (Textboxes, Lines, Rectangles, etc) do not
> > overlap. This usually causes the report to behave oddly in HTML as it
> > cannot overlap html objects very well. Usually you can avoid
> > overlapping items by using a table for your data region, instead of the
> > freeform List. Also, check the padding of your textboxes, and increase
> > the padding if needed.
> >
> > Textboxes do not grow horizontally as this is the layout of the report
> > and is the behavior by design. You should increase the width of your
> > textboxes to the max size that you can within your report layout for
> > the data that will be displayed in them. You can set the CanGrow
> > property to true, which basically allows the renderer to wrap the text
> > to another line(s), like you said, controlling vertical sizing.
> >
> > A lot of times, the result you get from viewing the report in the
> > viewer in HTML will not be exactly the same as when printing or
> > exporting to PDF or TIFF. The latter are print layout formats, and
> > will render the reports slightly different, because their media is
> > paper. For example, if you report has a page footer, in HTML, the
> > footer will show immediately after last item on the page, even if the
> > item is in the "middle" of the page, because HTML does not have concept
> > of "page sizes". If you print it or export to PDF, you will notice
> > that the renderer places the page footer at the bottom of the paper
> > page.
> >
> > Hope this helps you!
> >
> > Regards,
> > Thiago Silva, MCAD.NET
> >
> >
> > On Nov 22, 7:22 am, "Daniel Billingsley"
> > <DanielBillings...@.newsgroup.nospam> wrote:
> >> I've created a few reporting services local (Visual Studio) reports to
> >> see
> >> if this is a viable enterprise reporting option. I'm having rather
> >> abysmal
> >> experience with the report viewer.
> >>
> >> I design my report in the designer and it looks great. I run the
> >> application and view it on the screen and see
> >> - The left edges of text in text boxes is "clipped", as if the text is
> >> running outside the textbox margin or something
> >> - Some textboxes have switched to multiline as if it isn't long enough to
> >> display the contents, but the textbox isn't tall enough for that and what
> >> displays is just gobbledy-gook.
> >>
> >> If I switch the view to print layout mode the clipping is still there but
> >> the textboxes now display the entire contents horizontally like they did
> >> in
> >> the designer.
> >>
> >> In any case, if I print the report from the viewer it comes out pretty
> >> much
> >> like it looked in the designer.
> >>
> >> So, to recap:
> >> - Left edges of text boxes are clipped in the viewer
> >> - Reports layout like I designed them when in print layout mode but not
> >> otherwise
> >> - Printed reports don't look like they do when viewed on the screen
> >>
> >> I must be doing something horribly wrong or have a misunderstanding of
> >> the
> >> paradigm, because in my mind this is ridiculous for a reporting tool to
> >> behave this way. I understand the CanGrow property, but it only controls
> >> vertical sizing and in order to preserve my report esthetics I would need
> >> it
> >> to grow horizontally.
> >
if this is a viable enterprise reporting option. I'm having rather abysmal
experience with the report viewer.
I design my report in the designer and it looks great. I run the
application and view it on the screen and see
- The left edges of text in text boxes is "clipped", as if the text is
running outside the textbox margin or something
- Some textboxes have switched to multiline as if it isn't long enough to
display the contents, but the textbox isn't tall enough for that and what
displays is just gobbledy-gook.
If I switch the view to print layout mode the clipping is still there but
the textboxes now display the entire contents horizontally like they did in
the designer.
In any case, if I print the report from the viewer it comes out pretty much
like it looked in the designer.
So, to recap:
- Left edges of text boxes are clipped in the viewer
- Reports layout like I designed them when in print layout mode but not
otherwise
- Printed reports don't look like they do when viewed on the screen
I must be doing something horribly wrong or have a misunderstanding of the
paradigm, because in my mind this is ridiculous for a reporting tool to
behave this way. I understand the CanGrow property, but it only controls
vertical sizing and in order to preserve my report esthetics I would need it
to grow horizontally.Make sure you report items (Textboxes, Lines, Rectangles, etc) do not
overlap. This usually causes the report to behave oddly in HTML as it
cannot overlap html objects very well. Usually you can avoid
overlapping items by using a table for your data region, instead of the
freeform List. Also, check the padding of your textboxes, and increase
the padding if needed.
Textboxes do not grow horizontally as this is the layout of the report
and is the behavior by design. You should increase the width of your
textboxes to the max size that you can within your report layout for
the data that will be displayed in them. You can set the CanGrow
property to true, which basically allows the renderer to wrap the text
to another line(s), like you said, controlling vertical sizing.
A lot of times, the result you get from viewing the report in the
viewer in HTML will not be exactly the same as when printing or
exporting to PDF or TIFF. The latter are print layout formats, and
will render the reports slightly different, because their media is
paper. For example, if you report has a page footer, in HTML, the
footer will show immediately after last item on the page, even if the
item is in the "middle" of the page, because HTML does not have concept
of "page sizes". If you print it or export to PDF, you will notice
that the renderer places the page footer at the bottom of the paper
page.
Hope this helps you!
Regards,
Thiago Silva, MCAD.NET
On Nov 22, 7:22 am, "Daniel Billingsley"
<DanielBillings...@.newsgroup.nospam> wrote:
> I've created a few reporting services local (Visual Studio) reports to see
> if this is a viable enterprise reporting option. I'm having rather abysmal
> experience with the report viewer.
> I design my report in the designer and it looks great. I run the
> application and view it on the screen and see
> - The left edges of text in text boxes is "clipped", as if the text is
> running outside the textbox margin or something
> - Some textboxes have switched to multiline as if it isn't long enough to
> display the contents, but the textbox isn't tall enough for that and what
> displays is just gobbledy-gook.
> If I switch the view to print layout mode the clipping is still there but
> the textboxes now display the entire contents horizontally like they did in
> the designer.
> In any case, if I print the report from the viewer it comes out pretty much
> like it looked in the designer.
> So, to recap:
> - Left edges of text boxes are clipped in the viewer
> - Reports layout like I designed them when in print layout mode but not
> otherwise
> - Printed reports don't look like they do when viewed on the screen
> I must be doing something horribly wrong or have a misunderstanding of the
> paradigm, because in my mind this is ridiculous for a reporting tool to
> behave this way. I understand the CanGrow property, but it only controls
> vertical sizing and in order to preserve my report esthetics I would need it
> to grow horizontally.|||Well, I have to say I think not handling overlapping items is a ridiculous
limitation - one that surely has the graphics designers in the crowd
laughing their rears off. My use of it is not a list layout issue, it's a
graphic design issue, so using a table doesn't help. What I'm trying to
create is an effect similar to the windows forms GroupBox whereby there's a
box with a border that is interrupted for the "title" of the box.
Additionally, I'd like the title to be surrounded with a border itself.
This is not really all that complex graphically, so I think it's a rather
sever limitation that the rdlc report can't handle it.
Considering that increasing the width of the textbox doesn't really work.
The problem I'm trying to point out is that I can't predict what it will
look like at runtime while in the designer. And even if I put forth the
painful effort of making a change and then having to run the application to
see the results (another completely ridiculous limitation), the problem
still exists that it would look good in the view but when printed look like
I was an idiot because there'd be a bunch of whitespace in the end of the
box (border).
IMPORTANT NOTE - this is all really a problem with textboxes with borders in
general and really doesn't have anything to do with the fact that I am using
it in an overlapping way in this particular case.
I say again, for a report writer not to be able to predict the results, and
for the results to be that different between viewing and printing, is
unacceptable. Period. Yes, I would expect the differences in the way page
footers are handled because there are no "pages" in HTML. Of course it
would work that way. But not that the actual layout of the body of the
report would change so significantly.
I did not appreciate that the default for the viewer was an HTML view. This
seems like another case where the relationship to the SQL RS engine is a
liability.
"tafs7" <tsilva7@.gmail.com> wrote in message
news:1164347626.531755.16330@.l39g2000cwd.googlegroups.com...
> Make sure you report items (Textboxes, Lines, Rectangles, etc) do not
> overlap. This usually causes the report to behave oddly in HTML as it
> cannot overlap html objects very well. Usually you can avoid
> overlapping items by using a table for your data region, instead of the
> freeform List. Also, check the padding of your textboxes, and increase
> the padding if needed.
> Textboxes do not grow horizontally as this is the layout of the report
> and is the behavior by design. You should increase the width of your
> textboxes to the max size that you can within your report layout for
> the data that will be displayed in them. You can set the CanGrow
> property to true, which basically allows the renderer to wrap the text
> to another line(s), like you said, controlling vertical sizing.
> A lot of times, the result you get from viewing the report in the
> viewer in HTML will not be exactly the same as when printing or
> exporting to PDF or TIFF. The latter are print layout formats, and
> will render the reports slightly different, because their media is
> paper. For example, if you report has a page footer, in HTML, the
> footer will show immediately after last item on the page, even if the
> item is in the "middle" of the page, because HTML does not have concept
> of "page sizes". If you print it or export to PDF, you will notice
> that the renderer places the page footer at the bottom of the paper
> page.
> Hope this helps you!
> Regards,
> Thiago Silva, MCAD.NET
>
> On Nov 22, 7:22 am, "Daniel Billingsley"
> <DanielBillings...@.newsgroup.nospam> wrote:
>> I've created a few reporting services local (Visual Studio) reports to
>> see
>> if this is a viable enterprise reporting option. I'm having rather
>> abysmal
>> experience with the report viewer.
>> I design my report in the designer and it looks great. I run the
>> application and view it on the screen and see
>> - The left edges of text in text boxes is "clipped", as if the text is
>> running outside the textbox margin or something
>> - Some textboxes have switched to multiline as if it isn't long enough to
>> display the contents, but the textbox isn't tall enough for that and what
>> displays is just gobbledy-gook.
>> If I switch the view to print layout mode the clipping is still there but
>> the textboxes now display the entire contents horizontally like they did
>> in
>> the designer.
>> In any case, if I print the report from the viewer it comes out pretty
>> much
>> like it looked in the designer.
>> So, to recap:
>> - Left edges of text boxes are clipped in the viewer
>> - Reports layout like I designed them when in print layout mode but not
>> otherwise
>> - Printed reports don't look like they do when viewed on the screen
>> I must be doing something horribly wrong or have a misunderstanding of
>> the
>> paradigm, because in my mind this is ridiculous for a reporting tool to
>> behave this way. I understand the CanGrow property, but it only controls
>> vertical sizing and in order to preserve my report esthetics I would need
>> it
>> to grow horizontally.
>|||Hey, Daniel
Have you tried using a rectangle with borders, instead of a textbox as
the container? I don't think you'll get quite the same effect as the
GroupBox with the title, but at least your rectangle will serve as a
container for other items, and you can have a textbox on the inside of
this rectangle at the top left corner acting as the "title" (note the
"Parent" property in the property page of any textbox placed inside the
rectangle, and you should see the rectangle name)
There is really nothing that prevents you from overlapping items in a
report, however in this version of the product, it unfortunately
doesn't do well rendering overlaps in all renderers. This is mainly a
problem for the HTML rendering extension of the viewer. The same
report, when exported to PDF, will look perfect, though.
In the Visual Studio designer, when you preview a report that contains
overlapped items, you will get a warning in the output window but this
will not prevent you from running the report:
[rsOverlappingReportItems] The textbox 'textbox3' and the rectangle
'rectangle1' overlap. Overlapping report items are not supported in
all renderers.
Build complete -- 0 errors, 1 warnings
As far as the textbox stretching horizontally, it would make no sense
to allow for textboxes to do that because it could inherently stretch
the width of the report body and page width causing the report to print
extra pages just for the extra width, since the printed page size is a
property that is set in the report (e.g. 8.5x11in vs. 11x8.5in -
portrait or landscape letter).
Now, since you're using the RDLC format, I am assuming you have a
custom application that provides a UI to the user for selecting reports
and entering parameters (if required). If that's the case, then your
application is responsible for providing the data as well and then
handing that over to the ReportViewer control for rendering. As such,
there is no way to "preview" your report from the Visual Studio
designer, because it doesn't know where the data is coming from. I
would recommend developing your reports as regular RDL files to begin
with, so you can test on the VS designer. You can even preview it w/
the ReportViewer by right-clicking the report name in the Solution
Explorer and selecting "Run". This will spin off a separate process
with an external windows app hosting the ReportViewer (note that
because this is a windows app, it still won't render the actual HTML
results you'd get from Internet Explorer).
Once you're happy with the results, you can "doctor" your RDL file so
it becomes an RDLC (see http://www.gotreportviewer.com for more
details) that is usable by your custom application.
Hope this helps you.
If you need any references to help you further your skills in SSRS, I
would recommend reading some of the SSRS team blogs for tips:
All about the ReportViewer - http://www.gotreportviewer.com/
Brian Welcker - http://blogs.msdn.com/bwelcker
Chris Hays - http://blogs.msdn.com/ChrisHays/ <= Sleazy Hacks for SSRS
:)
Tudor's blog - http://blogs.msdn.com/tudortr/
Lukasz Pawlowski - http://blogs.msdn.com/lukaszp/
Bob Meyers- http://blogs.msdn.com/bobmeyers
Regards,
Thiago Silva, MCAD.NET
Daniel Billingsley wrote:
> Well, I have to say I think not handling overlapping items is a ridiculous
> limitation - one that surely has the graphics designers in the crowd
> laughing their rears off. My use of it is not a list layout issue, it's a
> graphic design issue, so using a table doesn't help. What I'm trying to
> create is an effect similar to the windows forms GroupBox whereby there's a
> box with a border that is interrupted for the "title" of the box.
> Additionally, I'd like the title to be surrounded with a border itself.
> This is not really all that complex graphically, so I think it's a rather
> sever limitation that the rdlc report can't handle it.
> Considering that increasing the width of the textbox doesn't really work.
> The problem I'm trying to point out is that I can't predict what it will
> look like at runtime while in the designer. And even if I put forth the
> painful effort of making a change and then having to run the application to
> see the results (another completely ridiculous limitation), the problem
> still exists that it would look good in the view but when printed look like
> I was an idiot because there'd be a bunch of whitespace in the end of the
> box (border).
> IMPORTANT NOTE - this is all really a problem with textboxes with borders in
> general and really doesn't have anything to do with the fact that I am using
> it in an overlapping way in this particular case.
> I say again, for a report writer not to be able to predict the results, and
> for the results to be that different between viewing and printing, is
> unacceptable. Period. Yes, I would expect the differences in the way page
> footers are handled because there are no "pages" in HTML. Of course it
> would work that way. But not that the actual layout of the body of the
> report would change so significantly.
> I did not appreciate that the default for the viewer was an HTML view. This
> seems like another case where the relationship to the SQL RS engine is a
> liability.
> "tafs7" <tsilva7@.gmail.com> wrote in message
> news:1164347626.531755.16330@.l39g2000cwd.googlegroups.com...
> >
> > Make sure you report items (Textboxes, Lines, Rectangles, etc) do not
> > overlap. This usually causes the report to behave oddly in HTML as it
> > cannot overlap html objects very well. Usually you can avoid
> > overlapping items by using a table for your data region, instead of the
> > freeform List. Also, check the padding of your textboxes, and increase
> > the padding if needed.
> >
> > Textboxes do not grow horizontally as this is the layout of the report
> > and is the behavior by design. You should increase the width of your
> > textboxes to the max size that you can within your report layout for
> > the data that will be displayed in them. You can set the CanGrow
> > property to true, which basically allows the renderer to wrap the text
> > to another line(s), like you said, controlling vertical sizing.
> >
> > A lot of times, the result you get from viewing the report in the
> > viewer in HTML will not be exactly the same as when printing or
> > exporting to PDF or TIFF. The latter are print layout formats, and
> > will render the reports slightly different, because their media is
> > paper. For example, if you report has a page footer, in HTML, the
> > footer will show immediately after last item on the page, even if the
> > item is in the "middle" of the page, because HTML does not have concept
> > of "page sizes". If you print it or export to PDF, you will notice
> > that the renderer places the page footer at the bottom of the paper
> > page.
> >
> > Hope this helps you!
> >
> > Regards,
> > Thiago Silva, MCAD.NET
> >
> >
> > On Nov 22, 7:22 am, "Daniel Billingsley"
> > <DanielBillings...@.newsgroup.nospam> wrote:
> >> I've created a few reporting services local (Visual Studio) reports to
> >> see
> >> if this is a viable enterprise reporting option. I'm having rather
> >> abysmal
> >> experience with the report viewer.
> >>
> >> I design my report in the designer and it looks great. I run the
> >> application and view it on the screen and see
> >> - The left edges of text in text boxes is "clipped", as if the text is
> >> running outside the textbox margin or something
> >> - Some textboxes have switched to multiline as if it isn't long enough to
> >> display the contents, but the textbox isn't tall enough for that and what
> >> displays is just gobbledy-gook.
> >>
> >> If I switch the view to print layout mode the clipping is still there but
> >> the textboxes now display the entire contents horizontally like they did
> >> in
> >> the designer.
> >>
> >> In any case, if I print the report from the viewer it comes out pretty
> >> much
> >> like it looked in the designer.
> >>
> >> So, to recap:
> >> - Left edges of text boxes are clipped in the viewer
> >> - Reports layout like I designed them when in print layout mode but not
> >> otherwise
> >> - Printed reports don't look like they do when viewed on the screen
> >>
> >> I must be doing something horribly wrong or have a misunderstanding of
> >> the
> >> paradigm, because in my mind this is ridiculous for a reporting tool to
> >> behave this way. I understand the CanGrow property, but it only controls
> >> vertical sizing and in order to preserve my report esthetics I would need
> >> it
> >> to grow horizontally.
> >
Subscribe to:
Posts (Atom)