Diff header / footer for diff section?

I have an report and it's structure like:

PAGE HEADER A
PAGE HEADER B
PAGE HEADER C
---
DETAIL A
DETAIL B
DETAIL C
---
PAGE FOOTER A
PAGE FOOTER B
PAGE FOOTER C

DETAIL B and DETAIL C will begin on a new page (As I have checked "New Page Before" for this two section...), but the content for DETAIL B and DETAIL C will be 2 or 3 pages, not static content...

My question is, can the PAGE HEADER and PAGE FOOTER show up according to the DETAIL?

The target output is:

(let say, Detail A will begin on page 1, detail B will begin on page 2, and detail C will begin on page 4...)

(page 1)
============
PAGE HEADER A
-------
DETAIL A
-------
PAGE FOOTER A
============

(page 2,...)
============
PAGE HEADER B
-------
DETAIL B
-------
PAGE FOOTER B
============

(page 4,.....)
============
PAGE HEADER C
-------
DETAIL C
-------
PAGE FOOTER C
============

Can this be done on crystal report 10...?

Thanks for the help.wy don't you put the header and footer in the group header /footer instead of page header / footersql

Dev. to Testing Best Practices

I am looking for ideas on how to move changes made to a database structure (e.g. sprocs, udf, views, tables) on the development machine to the testing server without affecting the data on the testing machine.
The developent server and the test server are on separate networks.
Thanks,
ROB
Posted using Wimdows.net NntpNews Component -
Post Made from http://www.SqlJunkies.com/newsgroups Our newsgroup engine supports Post Alerts, Ratings, and Searching.
> without affecting the data on the testing machine.
What changes to the structure are going to affect the data? Could you be
more specific about what structure changes you are talking about?
Typically, we generate DDL scripts (CREATE PROC, ALTER PROC, ALTER TABLE,
etc.) and run them on the target server. In most cases, we do this in
conjunction with a source control tool.
What kind of "best practices" are you looking for? Minimum downtime,
maximum security, etc.? I don't really think there is a "best way" to
deploy database changes, but depending on your goals, they might make you
lean one way or another.
http://www.aspfaq.com/
(Reverse address to reply.)

Dev. to Testing Best Practices

I am looking for ideas on how to move changes made to a database structure (e.g. sprocs, udf, views, tables) on the development machine to the testing server without affecting the data on the testing machine.
The developent server and the test server are on separate networks.
Thanks,
ROB
--
Posted using Wimdows.net NntpNews Component -
Post Made from http://www.SqlJunkies.com/newsgroups Our newsgroup engine supports Post Alerts, Ratings, and Searching.> without affecting the data on the testing machine.
What changes to the structure are going to affect the data? Could you be
more specific about what structure changes you are talking about?
Typically, we generate DDL scripts (CREATE PROC, ALTER PROC, ALTER TABLE,
etc.) and run them on the target server. In most cases, we do this in
conjunction with a source control tool.
What kind of "best practices" are you looking for? Minimum downtime,
maximum security, etc.? I don't really think there is a "best way" to
deploy database changes, but depending on your goals, they might make you
lean one way or another.
--
http://www.aspfaq.com/
(Reverse address to reply.)

Dev. to Testing Best Practices

I am looking for ideas on how to move changes made to a database structure (
e.g. sprocs, udf, views, tables) on the development machine to the testing s
erver without affecting the data on the testing machine.
The developent server and the test server are on separate networks.
Thanks,
ROB
Posted using Wimdows.net NntpNews Component -
Post Made from http://www.SqlJunkies.com/newsgroups Our newsgroup engine sup
ports Post Alerts, Ratings, and Searching.> without affecting the data on the testing machine.
What changes to the structure are going to affect the data? Could you be
more specific about what structure changes you are talking about?
Typically, we generate DDL scripts (CREATE PROC, ALTER PROC, ALTER TABLE,
etc.) and run them on the target server. In most cases, we do this in
conjunction with a source control tool.
What kind of "best practices" are you looking for? Minimum downtime,
maximum security, etc.? I don't really think there is a "best way" to
deploy database changes, but depending on your goals, they might make you
lean one way or another.
http://www.aspfaq.com/
(Reverse address to reply.)