maximum width

When loading a report that another developer created, I got an error
message saying that the deserialization failed because the width value
needs to be between 0 and 85.3333 in. I was able to get around this by
opening the RDL file in notepad and changing the width values manually.
But my questions is, how was the developer able to set the width >
85.3333 if it was not allowed?Probably, the report was manually edited.
As for the 85.3 in limit - in RS 2000 SP2 it will increase to 160 in.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Bucky" <uw_badgers@.mail.com> wrote in message
news:1103826459.105803.261470@.f14g2000cwb.googlegroups.com...
> When loading a report that another developer created, I got an error
> message saying that the deserialization failed because the width value
> needs to be between 0 and 85.3333 in. I was able to get around this by
> opening the RDL file in notepad and changing the width values manually.
>
> But my questions is, how was the developer able to set the width >
> 85.3333 if it was not allowed?
>

Maximum page width in Crystal Reports 8

Hi. I'm new to the forum. I apologize if this is the wrong place to pose such a question, or if it's been answered in another thread. I searched and did not find anything.

I don't want to bog everyone down in the details, but I want to give at least a little background as to the problem.

We use Crystal Reports 8.0.1 in conjunction with PeopleSoft Financials 8 to produce positive pay files out of our pay cycle process-which creates checks for vendors. The positive pay file includes basic check information-check number, date, etc. The pay cycle uses the Crystal Report definition, and creates a .txt positive pay file.

Due to new bank requirements, we now have to add several new fields to the file. The Crystal report designer doesn't seem capable of letting me go any further to the right than I already am. On print setup, I changed the layout to landscape, and the paper type to tabloid, and this definitely gave me some extra room. However, I still need about another 100 characters or so.

Does anyone know of any way to expand the page width further than I already have?

Help is much appreciated!Hi

I faced the same problem.. you can try to create a new custom paper size for your printer and change the designer printer setup paper size..
I failed to create a new paper size..
i would like to change the page header of the report also.. can anyone help?

max width for input fixed width column

Is there a maximum width for fixed width column?

I'm trying to read in a flat file (which, admittedly, has one very wide column), and it keeps breaking because of truncation when it tries to read in the file.

Any ideas?

Jim Work
What is the error exactly?|||Error: 0xC02020A1 at Data Flow Task, Flat File Source [1]: Data conversion failed. The data conversion for column "Column 1" returned status value 4 and status text "Text was truncated or one or more characters had no match in the target code page.".

Error: 0xC020902A at Data Flow Task, Flat File Source [1]: The "output column "Column 1" (157)" failed because truncation occurred, and the truncation row disposition on "output column "Column 1" (157)" specifies failure on truncation. A truncation error occurred on the specified object of the specified component.

Error: 0xC0202092 at Data Flow Task, Flat File Source [1]: An error occurred while processing file "C:\data\sampleDepositFile1.txt" on data row 1.

Does that help?

|||Yes, it does.

Sounds to me like there are characters in the data that don't have a match in the codepage you are working with. Could be a non-unicode/unicode issue. Are there NULLs in the data? NULLs truncate strings as well.

What codepage are you using? 1252? What kind of data do you have in the file?|||1252 (ANSI - Latin I )

This is what the connection manager defaulted to, and I believe it matches up with my source data. Should I change it to (and go back and save the source data as) UTF-8?

Thanks for any insight you can give me!
|||How big is your column in the source file, and what have you defined in the flat file source? Pull it up in the advanced editor and ensure that the columns are the correct size there.

Max width for indexed column?

Is column width a factor for an indexed column? Would indexing a
VARCHAR(100) be a bad idea? Any links to discussion of this topic?
Thanks for your advice.
- Joe Geretz -
'bad' is of course a relative term...
Yes, width of an index will affect performance. This is a LONG topic, but
here a a few thoughts...
* width of a clustered index can be more important to worry about than a NC
index since a clustered index key is propogated through ALL the NC indexex.
* yes, width does matter. Intuitively, it just makes sense. There is less
CPU and much less IO involved for a 10 byte index than a 100 byte index.
Would it be quicker for you to read a list of 10 letter words or 100 letter
sentences? Of course that's a silly example, but yes... narrow indexes will
be better all things considered.
* having a wide index isn't the end of hte world and probably isn't a big
deal with smaller data sets.
* if you DO need to index wide char based fields and you are worred about
performance... you may want to consider creating a checksum based on the
chat column and indexing the checsum col (which will be an integer). That
would be much faster...
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Joseph Geretz" <jgeretz@.nospam.com> wrote in message
news:e7LEw0RiEHA.344@.TK2MSFTNGP10.phx.gbl...
> Is column width a factor for an indexed column? Would indexing a
> VARCHAR(100) be a bad idea? Any links to discussion of this topic?
> Thanks for your advice.
> - Joe Geretz -
>

Max width for indexed column?

Is column width a factor for an indexed column? Would indexing a
VARCHAR(100) be a bad idea? Any links to discussion of this topic?
Thanks for your advice.
- Joe Geretz -'bad' is of course a relative term...
Yes, width of an index will affect performance. This is a LONG topic, but
here a a few thoughts...
* width of a clustered index can be more important to worry about than a NC
index since a clustered index key is propogated through ALL the NC indexex.
* yes, width does matter. Intuitively, it just makes sense. There is less
CPU and much less IO involved for a 10 byte index than a 100 byte index.
Would it be quicker for you to read a list of 10 letter words or 100 letter
sentences? Of course that's a silly example, but yes... narrow indexes will
be better all things considered.
* having a wide index isn't the end of hte world and probably isn't a big
deal with smaller data sets.
* if you DO need to index wide char based fields and you are worred about
performance... you may want to consider creating a checksum based on the
chat column and indexing the checsum col (which will be an integer). That
would be much faster...
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Joseph Geretz" <jgeretz@.nospam.com> wrote in message
news:e7LEw0RiEHA.344@.TK2MSFTNGP10.phx.gbl...
> Is column width a factor for an indexed column? Would indexing a
> VARCHAR(100) be a bad idea? Any links to discussion of this topic?
> Thanks for your advice.
> - Joe Geretz -
>

Max width for indexed column?

Is column width a factor for an indexed column? Would indexing a
VARCHAR(100) be a bad idea? Any links to discussion of this topic?
Thanks for your advice.
- Joe Geretz -'bad' is of course a relative term...
Yes, width of an index will affect performance. This is a LONG topic, but
here a a few thoughts...
* width of a clustered index can be more important to worry about than a NC
index since a clustered index key is propogated through ALL the NC indexex.
* yes, width does matter. Intuitively, it just makes sense. There is less
CPU and much less IO involved for a 10 byte index than a 100 byte index.
Would it be quicker for you to read a list of 10 letter words or 100 letter
sentences? Of course that's a silly example, but yes... narrow indexes will
be better all things considered.
* having a wide index isn't the end of hte world and probably isn't a big
deal with smaller data sets.
* if you DO need to index wide char based fields and you are worred about
performance... you may want to consider creating a checksum based on the
chat column and indexing the checsum col (which will be an integer). That
would be much faster...
--
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Joseph Geretz" <jgeretz@.nospam.com> wrote in message
news:e7LEw0RiEHA.344@.TK2MSFTNGP10.phx.gbl...
> Is column width a factor for an indexed column? Would indexing a
> VARCHAR(100) be a bad idea? Any links to discussion of this topic?
> Thanks for your advice.
> - Joe Geretz -
>