Hi all,
I have several columns which store currency values (typically up to 4
integer values, plus two decimal places)
Using Enterprise Manager I can set a column as decimal type, but it doesn't
allow me to specify precision) and any values show as the integer amount plu
s
.00 (ie 123.45 shows as 123.00). I converted these fields to money, but
several stored procedures showed a slow-down.
What is the most efficient datatype for storing very low precision real
numbers? What went wrong with my decimal datatype?
Many thanks in advance!Within EM look at the bottom half of the window. You will see a precision
and scale attribute there.
Keith Kratochvil
"GeorgeBR" <GeorgeBR@.discussions.microsoft.com> wrote in message
news:B8499051-76E7-4F2E-8650-971709333F6D@.microsoft.com...
> Hi all,
> I have several columns which store currency values (typically up to 4
> integer values, plus two decimal places)
> Using Enterprise Manager I can set a column as decimal type, but it
> doesn't
> allow me to specify precision) and any values show as the integer amount
> plus
> .00 (ie 123.45 shows as 123.00). I converted these fields to money, but
> several stored procedures showed a slow-down.
> What is the most efficient datatype for storing very low precision real
> numbers? What went wrong with my decimal datatype?
> Many thanks in advance!|||Also, don't use the money type. In addition to the performance issues you
are seeing, you will get rounding errors with money.
"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
news:e$STqrafGHA.1208@.TK2MSFTNGP02.phx.gbl...
> Within EM look at the bottom half of the window. You will see a precision
> and scale attribute there.
>
> --
> Keith Kratochvil
>
> "GeorgeBR" <GeorgeBR@.discussions.microsoft.com> wrote in message
> news:B8499051-76E7-4F2E-8650-971709333F6D@.microsoft.com...
>
Showing posts with label real. Show all posts
Showing posts with label real. Show all posts
Sunday, March 25, 2012
Saturday, February 25, 2012
Best image format for screen & print?
We are having real problems getting external report (from a URL) images of a
good quality consistently for both screen and PDF print.
Can anyone advise as to the best image format, sizing option, resolution,
etc. for SQL 2K reporting services SP1?
Thanks,
ChrisChris,
I find it best to design to the printed page size.
I'm using A4 landscape generally, I guess it would apply equally well
to US Letter.
I set the page width to 29.7cm, page height to 21cm - you need to make
sure this is set right so that the PDF document is paginated correctly.
I use margins of 0.5cm all round (NB:Some printers may not be able to
handle margins this small all the way round).
The report body is then set to 28.7cm (page width - left & right
margin). If you ever make this wider, i.e. by increasing the width of a
table beyond this, it will start splitting onto 2 pages in PDF. The
report body MUST fit inside the printable width, this is the common
cause of blank pages printing out.
I have found that these reports translate well for HTML display on a
1024x768 res. screen. The only caveat is the page header scrolling off
the screen. If you limit the number of rows per page to suit the screen
display, you'll end up with loads of empty space on the printed pages!
Hope that helps,
Chris.
Chris Lewis wrote:
> We are having real problems getting external report (from a URL)
> images of a good quality consistently for both screen and PDF print.
> Can anyone advise as to the best image format, sizing option,
> resolution, etc. for SQL 2K reporting services SP1?
> Thanks,
> Chris|||Thanks Chris.
Can you advise on the types of images that you embed or reference in your
reports - jpegs, gifs, etc. This is what we are having real difficulty
with - our images either look good on screen (HTML) *or* in PDF - we don't
seem to be able to get both to look good with the same image?
Thanks,
Chris
"Chris McGuigan" <chris.mcguigan@.zycko.com> wrote in message
news:uCbIRZoEFHA.3992@.tk2msftngp13.phx.gbl...
> Chris,
> I find it best to design to the printed page size.
> I'm using A4 landscape generally, I guess it would apply equally well
> to US Letter.
> I set the page width to 29.7cm, page height to 21cm - you need to make
> sure this is set right so that the PDF document is paginated correctly.
> I use margins of 0.5cm all round (NB:Some printers may not be able to
> handle margins this small all the way round).
> The report body is then set to 28.7cm (page width - left & right
> margin). If you ever make this wider, i.e. by increasing the width of a
> table beyond this, it will start splitting onto 2 pages in PDF. The
> report body MUST fit inside the printable width, this is the common
> cause of blank pages printing out.
> I have found that these reports translate well for HTML display on a
> 1024x768 res. screen. The only caveat is the page header scrolling off
> the screen. If you limit the number of rows per page to suit the screen
> display, you'll end up with loads of empty space on the printed pages!
> Hope that helps,
> Chris.
> Chris Lewis wrote:
> > We are having real problems getting external report (from a URL)
> > images of a good quality consistently for both screen and PDF print.
> >
> > Can anyone advise as to the best image format, sizing option,
> > resolution, etc. for SQL 2K reporting services SP1?
> >
> > Thanks,
> >
> > Chris
>|||I find GIFs seem to scale better, but if your images are predominately
photographic JPEG will probably perform better. I design them so that
they are shown at their native size on the screen which means they are
normally scaled up a bit on PDF. The trick is to avoid images being
scaled up heavily from their original size. This might mean larger
image files, but you don't get something for nothing!
I'm generally using images as backgrounds, but if you're using the
image control then avoid setting the 'Sizing' property to 'Fit' or 'Fit
Proportional' use 'AutoSize' or 'Clip'. That way you avoid rescaling.
If that's not possible then always use 'Fit Proportional'.
Regards,
Chris.
Chris Lewis wrote:
> Thanks Chris.
> Can you advise on the types of images that you embed or reference in
> your reports - jpegs, gifs, etc. This is what we are having real
> difficulty with - our images either look good on screen (HTML) or in
> PDF - we don't seem to be able to get both to look good with the same
> image?
> Thanks,
> Chris
> "Chris McGuigan" <chris.mcguigan@.zycko.com> wrote in message
> news:uCbIRZoEFHA.3992@.tk2msftngp13.phx.gbl...
> > Chris,
> > I find it best to design to the printed page size.
> > I'm using A4 landscape generally, I guess it would apply equally
> > well to US Letter.
> > I set the page width to 29.7cm, page height to 21cm - you need to
> > make sure this is set right so that the PDF document is paginated
> > correctly.
> >
> > I use margins of 0.5cm all round (NB:Some printers may not be able
> > to handle margins this small all the way round).
> > The report body is then set to 28.7cm (page width - left & right
> > margin). If you ever make this wider, i.e. by increasing the width
> > of a table beyond this, it will start splitting onto 2 pages in
> > PDF. The report body MUST fit inside the printable width, this is
> > the common cause of blank pages printing out.
> >
> > I have found that these reports translate well for HTML display on a
> > 1024x768 res. screen. The only caveat is the page header scrolling
> > off the screen. If you limit the number of rows per page to suit
> > the screen display, you'll end up with loads of empty space on the
> > printed pages!
> >
> > Hope that helps,
> >
> > Chris.
> >
> > Chris Lewis wrote:
> >
> > > We are having real problems getting external report (from a URL)
> > > images of a good quality consistently for both screen and PDF
> > > print.
> > >
> > > Can anyone advise as to the best image format, sizing option,
> > > resolution, etc. for SQL 2K reporting services SP1?
> > >
> > > Thanks,
> > >
> > > Chris
> >|||Thanks again Chris, I'll go away and try out your suggestions.
Chris
"Chris McGuigan" <chris.mcguigan@.zycko.com> wrote in message
news:#YOJZwoEFHA.1392@.tk2msftngp13.phx.gbl...
> I find GIFs seem to scale better, but if your images are predominately
> photographic JPEG will probably perform better. I design them so that
> they are shown at their native size on the screen which means they are
> normally scaled up a bit on PDF. The trick is to avoid images being
> scaled up heavily from their original size. This might mean larger
> image files, but you don't get something for nothing!
> I'm generally using images as backgrounds, but if you're using the
> image control then avoid setting the 'Sizing' property to 'Fit' or 'Fit
> Proportional' use 'AutoSize' or 'Clip'. That way you avoid rescaling.
> If that's not possible then always use 'Fit Proportional'.
> Regards,
> Chris.
> Chris Lewis wrote:
> > Thanks Chris.
> >
> > Can you advise on the types of images that you embed or reference in
> > your reports - jpegs, gifs, etc. This is what we are having real
> > difficulty with - our images either look good on screen (HTML) or in
> > PDF - we don't seem to be able to get both to look good with the same
> > image?
> >
> > Thanks,
> >
> > Chris
> >
> > "Chris McGuigan" <chris.mcguigan@.zycko.com> wrote in message
> > news:uCbIRZoEFHA.3992@.tk2msftngp13.phx.gbl...
> > > Chris,
> > > I find it best to design to the printed page size.
> > > I'm using A4 landscape generally, I guess it would apply equally
> > > well to US Letter.
> > > I set the page width to 29.7cm, page height to 21cm - you need to
> > > make sure this is set right so that the PDF document is paginated
> > > correctly.
> > >
> > > I use margins of 0.5cm all round (NB:Some printers may not be able
> > > to handle margins this small all the way round).
> > > The report body is then set to 28.7cm (page width - left & right
> > > margin). If you ever make this wider, i.e. by increasing the width
> > > of a table beyond this, it will start splitting onto 2 pages in
> > > PDF. The report body MUST fit inside the printable width, this is
> > > the common cause of blank pages printing out.
> > >
> > > I have found that these reports translate well for HTML display on a
> > > 1024x768 res. screen. The only caveat is the page header scrolling
> > > off the screen. If you limit the number of rows per page to suit
> > > the screen display, you'll end up with loads of empty space on the
> > > printed pages!
> > >
> > > Hope that helps,
> > >
> > > Chris.
> > >
> > > Chris Lewis wrote:
> > >
> > > > We are having real problems getting external report (from a URL)
> > > > images of a good quality consistently for both screen and PDF
> > > > print.
> > > >
> > > > Can anyone advise as to the best image format, sizing option,
> > > > resolution, etc. for SQL 2K reporting services SP1?
> > > >
> > > > Thanks,
> > > >
> > > > Chris
> > >
>
good quality consistently for both screen and PDF print.
Can anyone advise as to the best image format, sizing option, resolution,
etc. for SQL 2K reporting services SP1?
Thanks,
ChrisChris,
I find it best to design to the printed page size.
I'm using A4 landscape generally, I guess it would apply equally well
to US Letter.
I set the page width to 29.7cm, page height to 21cm - you need to make
sure this is set right so that the PDF document is paginated correctly.
I use margins of 0.5cm all round (NB:Some printers may not be able to
handle margins this small all the way round).
The report body is then set to 28.7cm (page width - left & right
margin). If you ever make this wider, i.e. by increasing the width of a
table beyond this, it will start splitting onto 2 pages in PDF. The
report body MUST fit inside the printable width, this is the common
cause of blank pages printing out.
I have found that these reports translate well for HTML display on a
1024x768 res. screen. The only caveat is the page header scrolling off
the screen. If you limit the number of rows per page to suit the screen
display, you'll end up with loads of empty space on the printed pages!
Hope that helps,
Chris.
Chris Lewis wrote:
> We are having real problems getting external report (from a URL)
> images of a good quality consistently for both screen and PDF print.
> Can anyone advise as to the best image format, sizing option,
> resolution, etc. for SQL 2K reporting services SP1?
> Thanks,
> Chris|||Thanks Chris.
Can you advise on the types of images that you embed or reference in your
reports - jpegs, gifs, etc. This is what we are having real difficulty
with - our images either look good on screen (HTML) *or* in PDF - we don't
seem to be able to get both to look good with the same image?
Thanks,
Chris
"Chris McGuigan" <chris.mcguigan@.zycko.com> wrote in message
news:uCbIRZoEFHA.3992@.tk2msftngp13.phx.gbl...
> Chris,
> I find it best to design to the printed page size.
> I'm using A4 landscape generally, I guess it would apply equally well
> to US Letter.
> I set the page width to 29.7cm, page height to 21cm - you need to make
> sure this is set right so that the PDF document is paginated correctly.
> I use margins of 0.5cm all round (NB:Some printers may not be able to
> handle margins this small all the way round).
> The report body is then set to 28.7cm (page width - left & right
> margin). If you ever make this wider, i.e. by increasing the width of a
> table beyond this, it will start splitting onto 2 pages in PDF. The
> report body MUST fit inside the printable width, this is the common
> cause of blank pages printing out.
> I have found that these reports translate well for HTML display on a
> 1024x768 res. screen. The only caveat is the page header scrolling off
> the screen. If you limit the number of rows per page to suit the screen
> display, you'll end up with loads of empty space on the printed pages!
> Hope that helps,
> Chris.
> Chris Lewis wrote:
> > We are having real problems getting external report (from a URL)
> > images of a good quality consistently for both screen and PDF print.
> >
> > Can anyone advise as to the best image format, sizing option,
> > resolution, etc. for SQL 2K reporting services SP1?
> >
> > Thanks,
> >
> > Chris
>|||I find GIFs seem to scale better, but if your images are predominately
photographic JPEG will probably perform better. I design them so that
they are shown at their native size on the screen which means they are
normally scaled up a bit on PDF. The trick is to avoid images being
scaled up heavily from their original size. This might mean larger
image files, but you don't get something for nothing!
I'm generally using images as backgrounds, but if you're using the
image control then avoid setting the 'Sizing' property to 'Fit' or 'Fit
Proportional' use 'AutoSize' or 'Clip'. That way you avoid rescaling.
If that's not possible then always use 'Fit Proportional'.
Regards,
Chris.
Chris Lewis wrote:
> Thanks Chris.
> Can you advise on the types of images that you embed or reference in
> your reports - jpegs, gifs, etc. This is what we are having real
> difficulty with - our images either look good on screen (HTML) or in
> PDF - we don't seem to be able to get both to look good with the same
> image?
> Thanks,
> Chris
> "Chris McGuigan" <chris.mcguigan@.zycko.com> wrote in message
> news:uCbIRZoEFHA.3992@.tk2msftngp13.phx.gbl...
> > Chris,
> > I find it best to design to the printed page size.
> > I'm using A4 landscape generally, I guess it would apply equally
> > well to US Letter.
> > I set the page width to 29.7cm, page height to 21cm - you need to
> > make sure this is set right so that the PDF document is paginated
> > correctly.
> >
> > I use margins of 0.5cm all round (NB:Some printers may not be able
> > to handle margins this small all the way round).
> > The report body is then set to 28.7cm (page width - left & right
> > margin). If you ever make this wider, i.e. by increasing the width
> > of a table beyond this, it will start splitting onto 2 pages in
> > PDF. The report body MUST fit inside the printable width, this is
> > the common cause of blank pages printing out.
> >
> > I have found that these reports translate well for HTML display on a
> > 1024x768 res. screen. The only caveat is the page header scrolling
> > off the screen. If you limit the number of rows per page to suit
> > the screen display, you'll end up with loads of empty space on the
> > printed pages!
> >
> > Hope that helps,
> >
> > Chris.
> >
> > Chris Lewis wrote:
> >
> > > We are having real problems getting external report (from a URL)
> > > images of a good quality consistently for both screen and PDF
> > > print.
> > >
> > > Can anyone advise as to the best image format, sizing option,
> > > resolution, etc. for SQL 2K reporting services SP1?
> > >
> > > Thanks,
> > >
> > > Chris
> >|||Thanks again Chris, I'll go away and try out your suggestions.
Chris
"Chris McGuigan" <chris.mcguigan@.zycko.com> wrote in message
news:#YOJZwoEFHA.1392@.tk2msftngp13.phx.gbl...
> I find GIFs seem to scale better, but if your images are predominately
> photographic JPEG will probably perform better. I design them so that
> they are shown at their native size on the screen which means they are
> normally scaled up a bit on PDF. The trick is to avoid images being
> scaled up heavily from their original size. This might mean larger
> image files, but you don't get something for nothing!
> I'm generally using images as backgrounds, but if you're using the
> image control then avoid setting the 'Sizing' property to 'Fit' or 'Fit
> Proportional' use 'AutoSize' or 'Clip'. That way you avoid rescaling.
> If that's not possible then always use 'Fit Proportional'.
> Regards,
> Chris.
> Chris Lewis wrote:
> > Thanks Chris.
> >
> > Can you advise on the types of images that you embed or reference in
> > your reports - jpegs, gifs, etc. This is what we are having real
> > difficulty with - our images either look good on screen (HTML) or in
> > PDF - we don't seem to be able to get both to look good with the same
> > image?
> >
> > Thanks,
> >
> > Chris
> >
> > "Chris McGuigan" <chris.mcguigan@.zycko.com> wrote in message
> > news:uCbIRZoEFHA.3992@.tk2msftngp13.phx.gbl...
> > > Chris,
> > > I find it best to design to the printed page size.
> > > I'm using A4 landscape generally, I guess it would apply equally
> > > well to US Letter.
> > > I set the page width to 29.7cm, page height to 21cm - you need to
> > > make sure this is set right so that the PDF document is paginated
> > > correctly.
> > >
> > > I use margins of 0.5cm all round (NB:Some printers may not be able
> > > to handle margins this small all the way round).
> > > The report body is then set to 28.7cm (page width - left & right
> > > margin). If you ever make this wider, i.e. by increasing the width
> > > of a table beyond this, it will start splitting onto 2 pages in
> > > PDF. The report body MUST fit inside the printable width, this is
> > > the common cause of blank pages printing out.
> > >
> > > I have found that these reports translate well for HTML display on a
> > > 1024x768 res. screen. The only caveat is the page header scrolling
> > > off the screen. If you limit the number of rows per page to suit
> > > the screen display, you'll end up with loads of empty space on the
> > > printed pages!
> > >
> > > Hope that helps,
> > >
> > > Chris.
> > >
> > > Chris Lewis wrote:
> > >
> > > > We are having real problems getting external report (from a URL)
> > > > images of a good quality consistently for both screen and PDF
> > > > print.
> > > >
> > > > Can anyone advise as to the best image format, sizing option,
> > > > resolution, etc. for SQL 2K reporting services SP1?
> > > >
> > > > Thanks,
> > > >
> > > > Chris
> > >
>
Friday, February 24, 2012
benefits to use collations BIN vs windows
Hi
which are the real benefits to use collations BIN vs for example
Latin1_General_Ci_AS.
Or only it is for the order of the data, this always utilizing types of data
unicode.
ThankOn Tue, 9 Jan 2007 09:28:01 -0800, sqlextreme wrote:
>Hi
>which are the real benefits to use collations BIN vs for example
>Latin1_General_Ci_AS.
>Or only it is for the order of the data, this always utilizing types of dat
a
>unicode.
Hi sqlextreme,
The most important consideration should be how you generally want to
compare data. What do the users expect? Do they expect to find
"Washington" when entering "washington" as search string? Should
"Dsseldorf" be returned when searching "Dusseldorf"? Would they be
surprised to find "aaron" after "Zelazny" if the data is supposed to be
ordered?
The only advantage of using binary collation that I know of is that it's
(slightly) faster.
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
which are the real benefits to use collations BIN vs for example
Latin1_General_Ci_AS.
Or only it is for the order of the data, this always utilizing types of data
unicode.
ThankOn Tue, 9 Jan 2007 09:28:01 -0800, sqlextreme wrote:
>Hi
>which are the real benefits to use collations BIN vs for example
>Latin1_General_Ci_AS.
>Or only it is for the order of the data, this always utilizing types of dat
a
>unicode.
Hi sqlextreme,
The most important consideration should be how you generally want to
compare data. What do the users expect? Do they expect to find
"Washington" when entering "washington" as search string? Should
"Dsseldorf" be returned when searching "Dusseldorf"? Would they be
surprised to find "aaron" after "Zelazny" if the data is supposed to be
ordered?
The only advantage of using binary collation that I know of is that it's
(slightly) faster.
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
Subscribe to:
Posts (Atom)