Forcing section break to odd pages

Hi - I'm new to this forum and fairly new to Crystal. Using 9.0. Because we print two-sided, I need to force a section break to start on next available odd numbered page so that I can treat the printed sections as separate documents (e.g. I don't want 1st page of new section to print on back of preceeding section). These sections are anywhere from 10 - 18 pages in length, and it is a huge report - over 11,000 pages. I'm pretty sure that there is a way to do this but I don't have time to fumble around with it. I already have 10 hours in this one report!

Thanks in advance
RobinI wrote a report recently that needed something simular, prehaps you can try this. The report prints a list of people at a specific place. Sometimes the place (group one) has lots of people and stems onto two pages and other times it fits on one page. As I'm duplex printing, I need to check whether the pages are even or odd and thus to include a page break or not.

In the section expect, I added a new group footer. In both group footer 1a and 1b I checked the 'new page after'. Then in group footer 1b, I added

Right (ToText(PageNumber),1) in ["0","2","4","6","8"]

which causes my report only to add a blank page after group one has finished if the current page number ends in any of the values above.

Hope it helps.

FOR XML EXPLICIT and namespaces

I'm trying to get a fairly complex structure from SQL Server 2000 to a client via classes generated with an xsd file and transferred through Web Services.
I can get the SQL stuff to work nicely if I have no tragetNamespace in the xsd.
However, then I cannot create a client proxy for my web service.
If I specify a (matching) targetNamespace in the web service description and the xsd file then I can create a proxy. However, at this point the XML produced by the SQL FOR XML EXPLICIT no longer validates.
I imagine this will be fixed if I specifiy a target namespace for my FOR XML EXPLICIT query (that is the root element should have a targetNamespace attribute).
I cannot see how to do this. There is sem reference to templates, but I believe these are use from http and I can't see any logical way to embed these in my SPROCS or ExecuteXmlReader calls.
Iain
"Iain" wrote:

> I'm trying to get a fairly complex structure from SQL Server 2000 to a client via classes generated with an xsd file and transferred through Web Services.
> I can get the SQL stuff to work nicely if I have no tragetNamespace in the xsd.
...
Well, I found somewhere someone putting the xmlns in as a separate column in the select query. So ...
'http://idcl.co.uk/PBWebAdmin' as [OrderBatch!1!xmlns],
and equivalent nulls in all the union locations.
This resulted in a query that worked sort of. Now for some reason it was rejecting the name and address elements (<FullName ..>, <Add1 ..>) in a <DeliveryAddress> element a couple of nests down.
I fixed this by changing the elements in the element to attributes.
I don't know why this worked.
Iain
|||Adding xmlns or xmlns:foo (and then using !foo:bar) columns as you do are
the way to add namespaces in FOR XML currently (note that the PATH mode in
Beta2 will not support this and I am working on getting a better solution
for at least the PATH mode made available in Beta3).
If you use xmlns without specifying a prefix, all descending elements will
be in that namespace (unless another xmlns overwrites it). If your schema
does not allow those elements to be in that namespace, you may have a
problem.
Attributes on the other hand are never part of the default namespace. They
belong to the element unless an explicit namespace prefix has been
associated.
So this difference may account for what you see.
HTH
Michael
"Iain" <Iain@.discussions.microsoft.com> wrote in message
news:4B201E22-E0AF-4B12-9D98-E8B2DE3BD143@.microsoft.com...
> "Iain" wrote:
> ...
> Well, I found somewhere someone putting the xmlns in as a separate column
> in the select query. So ...
> 'http://idcl.co.uk/PBWebAdmin' as [OrderBatch!1!xmlns],
> and equivalent nulls in all the union locations.
> This resulted in a query that worked sort of. Now for some reason it was
> rejecting the name and address elements (<FullName ..>, <Add1 ..>) in a
> <DeliveryAddress> element a couple of nests down.
> I fixed this by changing the elements in the element to attributes.
> I don't know why this worked.
> Iain
>