Showing posts with label back. Show all posts
Showing posts with label back. Show all posts

Friday, March 30, 2012

Print on back side of 1st page only

I have a SRS report that we are using as an invoice. I want to print out terms on the backside of the 1st page. Is this possible? Any ideas on how to go about doing this? I think the best way to go about doing this is to print the whole report double sided, and leave every 'even numbered' page blank expcept page 2, where the terms would print. I'm just not sure how to go about doing this in SRS.

Any help would be appreciated.

Randy

To start out with, can you be sure that content for each of the subsequent pages (page 3 and up, I mean) will be less than a page in length, with explicit page breaks between each, or does the content have to "flow" through pages 3, 4, etc without explicit page breaks? Does the content for page 1, similarly, have a known length, or can you force it to have a known length?

This is a cool problem <s>.

>L<

|||

The report is an invoice report. Page 1 will contain some header information (logo, address, customer, etc) and then will begin to list invoice lines. More than likely these invoice lines will carry over into multiple pages depending on how many items the customer ordered. In this case, page 1 would need to print with all of my header information and as much invoice line information as will fit, then page 2 would need to print terms, then page 3 should continue where page 1 left off. Page 4 would then need to be printed blank (since we are printing double sided) and page 5 would continue where page 3 left off, etc, etc. The challenge is telling SQL, "OK, now that we are on page 2, print this instead" and then, "now that we are on page 3, continue printing."

Thanks for any help you can provide.

Randy

Example:

Page 1 - Header, and body section

Page 2 - Terms

Page 3 - Body section from page 1 continued (if needed)

Page 4 - Blank

Page 5 - Body section from page 3 continued (if needed)

Page 6 - Blank

Page 7 - Body section from page 5 continued (if needed)

Page 8 - Blank

etc, etc

|||

>> No explicit page breaks

That's what I was afraid of -- makes things a little more complex, but I think it can be done... sorry for the delay in response...

OK, this is really cool. And I tried it a bunch of other ways, some of which might work and be less wierd -- but this really does work perfectly and doesn't disturb the "preview" layout at all -- it will only affect the print and PDF layout (and presumably other renderers that go to fixed page dimensions).

Here's how it works: It depends on something that usually annoys the heck out of us: the behavior of "wide" report designs in terms of page breaks for fixed page layouts such as print and PDF.

This is what you do:

1) First, figure out how you are going to separate the content of the first page from other pages and design your report with *two* tables, one for first page and one for the other pages. The first table obviously has your header while the second does not.

I did this by creating a SELECT statement that included a row number using SQL Server capabilities, because you can't filter or break by the the reporting RowNumber() function. You can do this in other environments as well -- in another thread somewhere here I show a worked example for doing it in SQL 2000 -- and you could also just use two datasets, one for each table. But in SQL 2005 it's really easy to do this:

Code Snippet


SELECT Row_Number() OVER (ORDER BY Whatever) As MyRowNum,*
FROM YourData ORDER BY Whatever

2) Now you make sure you only have the right details for each table. In my example, it worked out to have these two filters. If you split your data by some other method into one dataset for each of the tables , you don't need to do this:

Code Snippet


=Fields!MyRowNum.Value <= =15 ' first table

=Fields!MyRowNum.Value > =15 ' second table

3) Design your two tables so that they fit within the normal printable page limits -- if your paper size is, for example, 8.5 * 11, you should make sure that the tables are no wider than will print properly in this normally.

4) Here's the trick: You need to make the layout (page size -- *not* interactive page size) wider than will print properly for your page set up.

Horizontally across from table #1 , you put a rectangle (or whatever) holding your Terms details for the invoice.

Horizontally across from table #2, you don't need to put anything.

The layout ends up looking something like this:

Real layout (say, 7.5") a bit of space for comfort addtl layout, forcing the break

Header information, part of Table number one, plus the details that fit on page 1

Your terms go here Table number two with the rest of your details

The extra layout you put in should not be any more than 8" wide (in the example where the page is 8.5" wide) and preferably it should be a bit less.

The result is exactly what you want and what we usually do not want but get by accident, when we design page layouts that don't fit in a fixed page size:

the terms are pushed to page 2 and each appearance of table #2, starting with page 3, gets followed by an extra blank page...

Whaddya think?

>L<

Monday, March 26, 2012

Primary Keys

HI ,

I accidently removed the primary keys from my table by mistake. Is there anyway ,That i can get the PK's back to what is used to be. Need Help pls..... When I try "resetting" the PK I kep getting this error:

'table_name' table
- Unable to create index 'PK_tablename'.
ODBC error: [Microsoft][ODBC SQL Server Driver][SQL Server]CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 1. Most significant primary key is '1'.
[Microsoft][ODBC SQL Server Driver][SQL Server]Could not create constraint. See previous errors.
[Microsoft][ODBC SQL Server Driver][SQL Server]Warning: The table 'tDetail' has been created but its maximum row size (12521) exceeds the maximum number of bytes per row (8060). INSERT or UPDATE of a row in this table will fail if the resulting row length exceeds 8060 bytes.
[Microsoft][ODBC SQL Server Driver][SQL Server]The statement has been terminated.Before recreating the index you should handle all the rows that do not stand in the index condition (create duplicate- the Error root cause) .

You should do it by:
1. delete those rows
2. group by those rows
3. change Id of those rows|||Thanx for the help..but how do i do that?|||Thnx for the help...but how do I do that ...do I first delete all duplicates form the server and then re-assign the primary keys?

Yes !
1. first delete
2.re-assign the primary keys|||Originally posted by eschapir
Thnx for the help...but how do I do that ...do I first delete all duplicates form the server and then re-assign the primary keys?

Yes !
1. first delete
2.re-assign the primary keys

thanx

Friday, March 23, 2012

Primary keys

my PKs are out of order. my application relies on the order of these keys.
How do i put back on order ex.
current: desired:
1 1
2 2
5 3
6 4
7 5
Thanks...
drop and recreate the column as PK.
"mmc" <mmc@.discussions.microsoft.com> wrote in message
news:A7B43C62-8E2A-4100-AD63-09E4B8DB5139@.microsoft.com...
> my PKs are out of order. my application relies on the order of these keys.
> How do i put back on order ex.
> current: desired:
> 1 1
> 2 2
> 5 3
> 6 4
> 7 5
> Thanks...
|||This is a common misunderstanding. A table, by definition, has no order.
You cannot rely on any physical ordering of rows; a clustered index is not a
guarantee. The only safe way to guarantee order in a query is to use an
order by clause.
Beware of small test data sets and simplistic queries; these will appear to
support your invalid assumption.
"mmc" <mmc@.discussions.microsoft.com> wrote in message
news:A7B43C62-8E2A-4100-AD63-09E4B8DB5139@.microsoft.com...
> my PKs are out of order. my application relies on the order of these keys.
> How do i put back on order ex.
> current: desired:
> 1 1
> 2 2
> 5 3
> 6 4
> 7 5
> Thanks...
|||Use ORDER BY when you query the table. A table has no pre-determined order.
All you have done wrong is to fail to specify the order you require.
David Portas
SQL Server MVP
|||"Scott Morris" <bogus@.bogus.com> wrote in message
news:u4def5AzEHA.2036@.TK2MSFTNGP12.phx.gbl...
> This is a common misunderstanding. A table, by definition, has no order.
> You cannot rely on any physical ordering of rows; a clustered index is not
a
> guarantee. The only safe way to guarantee order in a query is to use an
> order by clause.
I thnk what mmc actually means is they are out of sequence.
My guess is he's using an IDENTITY value.

> Beware of small test data sets and simplistic queries; these will appear
to[vbcol=seagreen]
> support your invalid assumption.
> "mmc" <mmc@.discussions.microsoft.com> wrote in message
> news:A7B43C62-8E2A-4100-AD63-09E4B8DB5139@.microsoft.com...
keys.
>
|||As per Greg's suggestion, it looks like you may have an IDENTITY column with
gaps in the sequence (not "out of order" at all). Don't rely on the IDENTITY
column being sequential without gaps. You can't prevent gaps from happening
with IDENTITY so you should change your code to work correctly with this in
mind.
I would also suggest that it's unwise to rely on the sequential nature of
IDENTITY at all. There are situations where this will cause you problems and
the best rule is to assume NOTHING about the IDENTITY sequence and write
your code accordingly. Don't even assume an IDENTITY column will be unique
unless you have a unique constraint on it. Adding a DATETIME column to the
table is a better way to track the order of insertion, if that is your goal.
David Portas
SQL Server MVP
|||Thank you, David.
"David Portas" wrote:

> As per Greg's suggestion, it looks like you may have an IDENTITY column with
> gaps in the sequence (not "out of order" at all). Don't rely on the IDENTITY
> column being sequential without gaps. You can't prevent gaps from happening
> with IDENTITY so you should change your code to work correctly with this in
> mind.
> I would also suggest that it's unwise to rely on the sequential nature of
> IDENTITY at all. There are situations where this will cause you problems and
> the best rule is to assume NOTHING about the IDENTITY sequence and write
> your code accordingly. Don't even assume an IDENTITY column will be unique
> unless you have a unique constraint on it. Adding a DATETIME column to the
> table is a better way to track the order of insertion, if that is your goal.
> --
> David Portas
> SQL Server MVP
> --
>
>

Primary keys

my PKs are out of order. my application relies on the order of these keys.
How do i put back on order ex.
current: desired:
1 1
2 2
5 3
6 4
7 5
Thanks...drop and recreate the column as PK.
"mmc" <mmc@.discussions.microsoft.com> wrote in message
news:A7B43C62-8E2A-4100-AD63-09E4B8DB5139@.microsoft.com...
> my PKs are out of order. my application relies on the order of these keys.
> How do i put back on order ex.
> current: desired:
> 1 1
> 2 2
> 5 3
> 6 4
> 7 5
> Thanks...|||This is a common misunderstanding. A table, by definition, has no order.
You cannot rely on any physical ordering of rows; a clustered index is not a
guarantee. The only safe way to guarantee order in a query is to use an
order by clause.
Beware of small test data sets and simplistic queries; these will appear to
support your invalid assumption.
"mmc" <mmc@.discussions.microsoft.com> wrote in message
news:A7B43C62-8E2A-4100-AD63-09E4B8DB5139@.microsoft.com...
> my PKs are out of order. my application relies on the order of these keys.
> How do i put back on order ex.
> current: desired:
> 1 1
> 2 2
> 5 3
> 6 4
> 7 5
> Thanks...|||Use ORDER BY when you query the table. A table has no pre-determined order.
All you have done wrong is to fail to specify the order you require.
--
David Portas
SQL Server MVP
--|||"Scott Morris" <bogus@.bogus.com> wrote in message
news:u4def5AzEHA.2036@.TK2MSFTNGP12.phx.gbl...
> This is a common misunderstanding. A table, by definition, has no order.
> You cannot rely on any physical ordering of rows; a clustered index is not
a
> guarantee. The only safe way to guarantee order in a query is to use an
> order by clause.
I thnk what mmc actually means is they are out of sequence.
My guess is he's using an IDENTITY value.
> Beware of small test data sets and simplistic queries; these will appear
to
> support your invalid assumption.
> "mmc" <mmc@.discussions.microsoft.com> wrote in message
> news:A7B43C62-8E2A-4100-AD63-09E4B8DB5139@.microsoft.com...
> > my PKs are out of order. my application relies on the order of these
keys.
> > How do i put back on order ex.
> > current: desired:
> > 1 1
> > 2 2
> > 5 3
> > 6 4
> > 7 5
> > Thanks...
>|||As per Greg's suggestion, it looks like you may have an IDENTITY column with
gaps in the sequence (not "out of order" at all). Don't rely on the IDENTITY
column being sequential without gaps. You can't prevent gaps from happening
with IDENTITY so you should change your code to work correctly with this in
mind.
I would also suggest that it's unwise to rely on the sequential nature of
IDENTITY at all. There are situations where this will cause you problems and
the best rule is to assume NOTHING about the IDENTITY sequence and write
your code accordingly. Don't even assume an IDENTITY column will be unique
unless you have a unique constraint on it. Adding a DATETIME column to the
table is a better way to track the order of insertion, if that is your goal.
--
David Portas
SQL Server MVP
--|||Thank you, David.
"David Portas" wrote:
> As per Greg's suggestion, it looks like you may have an IDENTITY column with
> gaps in the sequence (not "out of order" at all). Don't rely on the IDENTITY
> column being sequential without gaps. You can't prevent gaps from happening
> with IDENTITY so you should change your code to work correctly with this in
> mind.
> I would also suggest that it's unwise to rely on the sequential nature of
> IDENTITY at all. There are situations where this will cause you problems and
> the best rule is to assume NOTHING about the IDENTITY sequence and write
> your code accordingly. Don't even assume an IDENTITY column will be unique
> unless you have a unique constraint on it. Adding a DATETIME column to the
> table is a better way to track the order of insertion, if that is your goal.
> --
> David Portas
> SQL Server MVP
> --
>
>

Primary keys

my PKs are out of order. my application relies on the order of these keys.
How do i put back on order ex.
current: desired:
1 1
2 2
5 3
6 4
7 5
Thanks...drop and recreate the column as PK.
"mmc" <mmc@.discussions.microsoft.com> wrote in message
news:A7B43C62-8E2A-4100-AD63-09E4B8DB5139@.microsoft.com...
> my PKs are out of order. my application relies on the order of these keys.
> How do i put back on order ex.
> current: desired:
> 1 1
> 2 2
> 5 3
> 6 4
> 7 5
> Thanks...|||This is a common misunderstanding. A table, by definition, has no order.
You cannot rely on any physical ordering of rows; a clustered index is not a
guarantee. The only safe way to guarantee order in a query is to use an
order by clause.
Beware of small test data sets and simplistic queries; these will appear to
support your invalid assumption.
"mmc" <mmc@.discussions.microsoft.com> wrote in message
news:A7B43C62-8E2A-4100-AD63-09E4B8DB5139@.microsoft.com...
> my PKs are out of order. my application relies on the order of these keys.
> How do i put back on order ex.
> current: desired:
> 1 1
> 2 2
> 5 3
> 6 4
> 7 5
> Thanks...|||Use ORDER BY when you query the table. A table has no pre-determined order.
All you have done wrong is to fail to specify the order you require.
David Portas
SQL Server MVP
--|||"Scott Morris" <bogus@.bogus.com> wrote in message
news:u4def5AzEHA.2036@.TK2MSFTNGP12.phx.gbl...
> This is a common misunderstanding. A table, by definition, has no order.
> You cannot rely on any physical ordering of rows; a clustered index is not
a
> guarantee. The only safe way to guarantee order in a query is to use an
> order by clause.
I thnk what mmc actually means is they are out of sequence.
My guess is he's using an IDENTITY value.

> Beware of small test data sets and simplistic queries; these will appear
to
> support your invalid assumption.
> "mmc" <mmc@.discussions.microsoft.com> wrote in message
> news:A7B43C62-8E2A-4100-AD63-09E4B8DB5139@.microsoft.com...
keys.[vbcol=seagreen]
>|||As per Greg's suggestion, it looks like you may have an IDENTITY column with
gaps in the sequence (not "out of order" at all). Don't rely on the IDENTITY
column being sequential without gaps. You can't prevent gaps from happening
with IDENTITY so you should change your code to work correctly with this in
mind.
I would also suggest that it's unwise to rely on the sequential nature of
IDENTITY at all. There are situations where this will cause you problems and
the best rule is to assume NOTHING about the IDENTITY sequence and write
your code accordingly. Don't even assume an IDENTITY column will be unique
unless you have a unique constraint on it. Adding a DATETIME column to the
table is a better way to track the order of insertion, if that is your goal.
David Portas
SQL Server MVP
--|||Thank you, David.
"David Portas" wrote:

> As per Greg's suggestion, it looks like you may have an IDENTITY column wi
th
> gaps in the sequence (not "out of order" at all). Don't rely on the IDENTI
TY
> column being sequential without gaps. You can't prevent gaps from happenin
g
> with IDENTITY so you should change your code to work correctly with this i
n
> mind.
> I would also suggest that it's unwise to rely on the sequential nature of
> IDENTITY at all. There are situations where this will cause you problems a
nd
> the best rule is to assume NOTHING about the IDENTITY sequence and write
> your code accordingly. Don't even assume an IDENTITY column will be unique
> unless you have a unique constraint on it. Adding a DATETIME column to the
> table is a better way to track the order of insertion, if that is your goa
l.
> --
> David Portas
> SQL Server MVP
> --
>
>

Wednesday, March 21, 2012

primary key in datarow after update works in access not in sql server

Heys

a while back i had to do a project with an access database, one of the biggest problems i had back then was gettting the primary key
of a datarow you had just inserted into the database.

After a long set of trial and error i came up with the following:

- add the tablemappings of a table
- call the dataadapte.fillschema method

then after inserting a new row into the database the primary key gets filled in automatically!

now thing is

i was hoping to duplicate this in sql server

but it doesn't seem to work at all

so after i insert a row into my datatable
and update it
the row is in the database
but in vb the datarow primary key is not filled in!
anyone have an idea?

prefereabely one that does not resort to stored procedures with return parameters etc

thx a million in advance!Try the solution in this post to get started. Hope this helps.
http://forums.asp.net/967888/ShowPost.aspx