Showing posts with label design. Show all posts
Showing posts with label design. Show all posts

Monday, March 26, 2012

Few Design and Programming Questions

I have a few questions regarding reports that I haven't found answers after a
little searching. Thanks for any help!
1. I need to create a few reports with some repeating pages. For example, in
one of them I need to have a cover page, then couple content pages, then a
summary page. I need to double print the content pages. There must be a
better way to achive this than manually copy-and-paste to duplicate those
pages in the report design, is there?
2. Is there a way to embed a PDF file into the report somehow? Say, at the
end of each report, I need to include a few pages of static information. Can
I somehow have the report server to pull out a PDF file instead of putting
those text into the report design?
3. Can I include other reports in a report?
4. Is there a way to control printing of the reports after I exported them
into PDF for printing? Say, I want page 3 and 4 print on both side of the
paper. I don't think this is possible, but asking to make sure.
5. Can I control the size of the parameter input area of the report at the
top portion of the report server? I need to disply 8 input boxes. Users need
to scroll down in the parameter area to see the last 2.
Thanks!No reply yet : ]
Does anyone know something about my question #2?
Or any suggestions on how to deal with complexed text/table formatting with
VS .NET 2003 report designer? It is so hard to make things look right, that's
why I wanted to just "attach" a PDF or word file for those static text.
"Xonic" wrote:
> I have a few questions regarding reports that I haven't found answers after a
> little searching. Thanks for any help!
> 1. I need to create a few reports with some repeating pages. For example, in
> one of them I need to have a cover page, then couple content pages, then a
> summary page. I need to double print the content pages. There must be a
> better way to achive this than manually copy-and-paste to duplicate those
> pages in the report design, is there?
> 2. Is there a way to embed a PDF file into the report somehow? Say, at the
> end of each report, I need to include a few pages of static information. Can
> I somehow have the report server to pull out a PDF file instead of putting
> those text into the report design?
> 3. Can I include other reports in a report?
> 4. Is there a way to control printing of the reports after I exported them
> into PDF for printing? Say, I want page 3 and 4 print on both side of the
> paper. I don't think this is possible, but asking to make sure.
> 5. Can I control the size of the parameter input area of the report at the
> top portion of the report server? I need to disply 8 input boxes. Users need
> to scroll down in the parameter area to see the last 2.
> Thanks!

Friday, March 23, 2012

Feedback on design issue sought

First, a brief backgrounder . . . I work for a small but quickly
growing company with a voracious appetite for data but limited
resources to provide the infrastructure I think they need to supply
this data.
The problem . . . Our primary operations application data, which
represents much of the data employees would like to access for various
reporting needs, is hosted in an off-site SQL Server 2005 database. I
would like to provide local access to this data so that A) people
aren't reporting off of a production operations database and B) we
don't have to worry about VPN's, network issues, etc. My understanding
is that I cannot mirror a 2005 database to a 2000 database. Is this
correct? If so, does anyone have suggestions for an alternative
approach to the problem? I could do some hokey thing with scripts and
scheduled tasks and move the nightly bak file around and restore it
using DTS or something like that, but I was thinking there must be a
more elegant way to address the issue.
Any thoughts? 24 hour latency of the data is acceptable.
Thanks,
RichYou can only mirror from SQL 2005 to SQL 2005 servers.
You might be able to use replication for this depending on what ports are
open on your respective firewalls, or you could also use log shipping and
send the logs and backup via ftp. DTS is another option.
--
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Rich" <rsbaier@.gmail.com> wrote in message
news:1161110521.900413.111550@.k70g2000cwa.googlegroups.com...
> First, a brief backgrounder . . . I work for a small but quickly
> growing company with a voracious appetite for data but limited
> resources to provide the infrastructure I think they need to supply
> this data.
> The problem . . . Our primary operations application data, which
> represents much of the data employees would like to access for various
> reporting needs, is hosted in an off-site SQL Server 2005 database. I
> would like to provide local access to this data so that A) people
> aren't reporting off of a production operations database and B) we
> don't have to worry about VPN's, network issues, etc. My understanding
> is that I cannot mirror a 2005 database to a 2000 database. Is this
> correct? If so, does anyone have suggestions for an alternative
> approach to the problem? I could do some hokey thing with scripts and
> scheduled tasks and move the nightly bak file around and restore it
> using DTS or something like that, but I was thinking there must be a
> more elegant way to address the issue.
> Any thoughts? 24 hour latency of the data is acceptable.
> Thanks,
> Rich
>|||On 17 Oct 2006 11:42:01 -0700, "Rich" <rsbaier@.gmail.com> wrote:
>Any thoughts? 24 hour latency of the data is acceptable.
Go with the .bak file.
J.|||Log Shipping could be a good solution for your situation.
--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"Rich" <rsbaier@.gmail.com> wrote in message
news:1161110521.900413.111550@.k70g2000cwa.googlegroups.com...
> First, a brief backgrounder . . . I work for a small but quickly
> growing company with a voracious appetite for data but limited
> resources to provide the infrastructure I think they need to supply
> this data.
> The problem . . . Our primary operations application data, which
> represents much of the data employees would like to access for various
> reporting needs, is hosted in an off-site SQL Server 2005 database. I
> would like to provide local access to this data so that A) people
> aren't reporting off of a production operations database and B) we
> don't have to worry about VPN's, network issues, etc. My understanding
> is that I cannot mirror a 2005 database to a 2000 database. Is this
> correct? If so, does anyone have suggestions for an alternative
> approach to the problem? I could do some hokey thing with scripts and
> scheduled tasks and move the nightly bak file around and restore it
> using DTS or something like that, but I was thinking there must be a
> more elegant way to address the issue.
> Any thoughts? 24 hour latency of the data is acceptable.
> Thanks,
> Rich
>sql

Feedback on design issue sought

First, a brief backgrounder . . . I work for a small but quickly
growing company with a voracious appetite for data but limited
resources to provide the infrastructure I think they need to supply
this data.
The problem . . . Our primary operations application data, which
represents much of the data employees would like to access for various
reporting needs, is hosted in an off-site SQL Server 2005 database. I
would like to provide local access to this data so that A) people
aren't reporting off of a production operations database and B) we
don't have to worry about VPN's, network issues, etc. My understanding
is that I cannot mirror a 2005 database to a 2000 database. Is this
correct? If so, does anyone have suggestions for an alternative
approach to the problem? I could do some hokey thing with scripts and
scheduled tasks and move the nightly bak file around and restore it
using DTS or something like that, but I was thinking there must be a
more elegant way to address the issue.
Any thoughts? 24 hour latency of the data is acceptable.
Thanks,
Rich
You can only mirror from SQL 2005 to SQL 2005 servers.
You might be able to use replication for this depending on what ports are
open on your respective firewalls, or you could also use log shipping and
send the logs and backup via ftp. DTS is another option.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Rich" <rsbaier@.gmail.com> wrote in message
news:1161110521.900413.111550@.k70g2000cwa.googlegr oups.com...
> First, a brief backgrounder . . . I work for a small but quickly
> growing company with a voracious appetite for data but limited
> resources to provide the infrastructure I think they need to supply
> this data.
> The problem . . . Our primary operations application data, which
> represents much of the data employees would like to access for various
> reporting needs, is hosted in an off-site SQL Server 2005 database. I
> would like to provide local access to this data so that A) people
> aren't reporting off of a production operations database and B) we
> don't have to worry about VPN's, network issues, etc. My understanding
> is that I cannot mirror a 2005 database to a 2000 database. Is this
> correct? If so, does anyone have suggestions for an alternative
> approach to the problem? I could do some hokey thing with scripts and
> scheduled tasks and move the nightly bak file around and restore it
> using DTS or something like that, but I was thinking there must be a
> more elegant way to address the issue.
> Any thoughts? 24 hour latency of the data is acceptable.
> Thanks,
> Rich
>
|||On 17 Oct 2006 11:42:01 -0700, "Rich" <rsbaier@.gmail.com> wrote:
>Any thoughts? 24 hour latency of the data is acceptable.
Go with the .bak file.
J.
|||Log Shipping could be a good solution for your situation.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"Rich" <rsbaier@.gmail.com> wrote in message
news:1161110521.900413.111550@.k70g2000cwa.googlegr oups.com...
> First, a brief backgrounder . . . I work for a small but quickly
> growing company with a voracious appetite for data but limited
> resources to provide the infrastructure I think they need to supply
> this data.
> The problem . . . Our primary operations application data, which
> represents much of the data employees would like to access for various
> reporting needs, is hosted in an off-site SQL Server 2005 database. I
> would like to provide local access to this data so that A) people
> aren't reporting off of a production operations database and B) we
> don't have to worry about VPN's, network issues, etc. My understanding
> is that I cannot mirror a 2005 database to a 2000 database. Is this
> correct? If so, does anyone have suggestions for an alternative
> approach to the problem? I could do some hokey thing with scripts and
> scheduled tasks and move the nightly bak file around and restore it
> using DTS or something like that, but I was thinking there must be a
> more elegant way to address the issue.
> Any thoughts? 24 hour latency of the data is acceptable.
> Thanks,
> Rich
>

Feedback on design issue sought

First, a brief backgrounder . . . I work for a small but quickly
growing company with a voracious appetite for data but limited
resources to provide the infrastructure I think they need to supply
this data.
The problem . . . Our primary operations application data, which
represents much of the data employees would like to access for various
reporting needs, is hosted in an off-site SQL Server 2005 database. I
would like to provide local access to this data so that A) people
aren't reporting off of a production operations database and B) we
don't have to worry about VPN's, network issues, etc. My understanding
is that I cannot mirror a 2005 database to a 2000 database. Is this
correct? If so, does anyone have suggestions for an alternative
approach to the problem? I could do some hokey thing with scripts and
scheduled tasks and move the nightly bak file around and restore it
using DTS or something like that, but I was thinking there must be a
more elegant way to address the issue.
Any thoughts? 24 hour latency of the data is acceptable.
Thanks,
RichYou can only mirror from SQL 2005 to SQL 2005 servers.
You might be able to use replication for this depending on what ports are
open on your respective firewalls, or you could also use log shipping and
send the logs and backup via ftp. DTS is another option.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Rich" <rsbaier@.gmail.com> wrote in message
news:1161110521.900413.111550@.k70g2000cwa.googlegroups.com...
> First, a brief backgrounder . . . I work for a small but quickly
> growing company with a voracious appetite for data but limited
> resources to provide the infrastructure I think they need to supply
> this data.
> The problem . . . Our primary operations application data, which
> represents much of the data employees would like to access for various
> reporting needs, is hosted in an off-site SQL Server 2005 database. I
> would like to provide local access to this data so that A) people
> aren't reporting off of a production operations database and B) we
> don't have to worry about VPN's, network issues, etc. My understanding
> is that I cannot mirror a 2005 database to a 2000 database. Is this
> correct? If so, does anyone have suggestions for an alternative
> approach to the problem? I could do some hokey thing with scripts and
> scheduled tasks and move the nightly bak file around and restore it
> using DTS or something like that, but I was thinking there must be a
> more elegant way to address the issue.
> Any thoughts? 24 hour latency of the data is acceptable.
> Thanks,
> Rich
>|||On 17 Oct 2006 11:42:01 -0700, "Rich" <rsbaier@.gmail.com> wrote:
>Any thoughts? 24 hour latency of the data is acceptable.
Go with the .bak file.
J.|||Log Shipping could be a good solution for your situation.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"Rich" <rsbaier@.gmail.com> wrote in message
news:1161110521.900413.111550@.k70g2000cwa.googlegroups.com...
> First, a brief backgrounder . . . I work for a small but quickly
> growing company with a voracious appetite for data but limited
> resources to provide the infrastructure I think they need to supply
> this data.
> The problem . . . Our primary operations application data, which
> represents much of the data employees would like to access for various
> reporting needs, is hosted in an off-site SQL Server 2005 database. I
> would like to provide local access to this data so that A) people
> aren't reporting off of a production operations database and B) we
> don't have to worry about VPN's, network issues, etc. My understanding
> is that I cannot mirror a 2005 database to a 2000 database. Is this
> correct? If so, does anyone have suggestions for an alternative
> approach to the problem? I could do some hokey thing with scripts and
> scheduled tasks and move the nightly bak file around and restore it
> using DTS or something like that, but I was thinking there must be a
> more elegant way to address the issue.
> Any thoughts? 24 hour latency of the data is acceptable.
> Thanks,
> Rich
>