Line Chart Help

Unfortunately this isn't as easy as it sounds. I am trying to build a chart just like the one in the attachment (I made it in Excel to show what I want). It's a simple line chart that reflects a trend of data over a period of time. However, there may be multiple entries on one day (such as the 24th in the example), but a single entry on another day.

Crystal wants to summarize the data and present ONE value for ONE day even if there are multiple entries in a day. How can I make it stop doing this? Are there any 3rd party vendors that have additional charts that can be installed?

Check out the attachments:
Chart.jpg - Excel Chart
cry_chart.jpg - Crystal Chart (notice 2 values for 7/23, but Crystal only shows 1 on the chart)

FYIIm running 8.5 because thats the only version my app will support.

I'd appreciate any help!Actually, CR not just shows you 1 value for 7/23/07 on the chart, it returns you sum of those 2 values for that date:

HGB ..... 10.3 .... 7/23/07
HGB ..... 7.9 ..... 7/23/07

If your Date field containes only date, I don't think you can get CR to show your values separately. But if this is a date_time field just formatted as date you can do next:
Open your Chart Expert ->Data. In the 'On change of' section, highlight your date_time field, then click the 'Order' button. I believe you have 'for each day' selected for the 'The section will be printed'.
Set it 'for each second' then you will get your desired result.|||That's what I meant when I said that Crystal sumarizes the data for one day and only shows one value.

Cool man. I'll try that and see if it works. I appreciate it!|||This worked! Thanks for the help.

Limits on rows in a table

Hi

We received the following in an email from a third-party supplier (who
naturally has a solution for the problem as described). It sounds like
gibberish to me, but does anyone have any comments?

<quote>
SQL in its current incarnation hits a performance brick wall when a
table contains more than about 75 million rows. This is not a
configuration limit as the table could be grown a lot larger but the
performance issue generates problems for ??; primarily during
search and retrieval of archived objects; although if the database
engine is being heavily hit for retrieval the archiving process can
slow down as well.
</quote
Chloe Crowder
British Librarychloe.crowder@.bl.uk wrote:
> Hi
> We received the following in an email from a third-party supplier (who
> naturally has a solution for the problem as described). It sounds like
> gibberish to me, but does anyone have any comments?
> <quote>
> SQL in its current incarnation hits a performance brick wall when a
> table contains more than about 75 million rows. This is not a
> configuration limit as the table could be grown a lot larger but the
> performance issue generates problems for ??; primarily during
> search and retrieval of archived objects; although if the database
> engine is being heavily hit for retrieval the archiving process can
> slow down as well.
> </quote
I've never heard something like this before. Maybe it's a problem
limited to a specific application. Maybe the app uses the DB in bad
ways (wrong indexing...)?

robert|||chloe.crowder@.bl.uk wrote:
> Hi
> We received the following in an email from a third-party supplier (who
> naturally has a solution for the problem as described). It sounds like
> gibberish to me, but does anyone have any comments?
> <quote>
> SQL in its current incarnation hits a performance brick wall when a
> table contains more than about 75 million rows. This is not a
> configuration limit as the table could be grown a lot larger but the
> performance issue generates problems for ??; primarily during
> search and retrieval of archived objects; although if the database
> engine is being heavily hit for retrieval the archiving process can
> slow down as well.
> </quote>
> Chloe Crowder
> British Library

"SQL in its current incarnation..."

SQL is a language and it has no such limitations. Did they mean to
refer to Microsoft SQL Server? Either way, their claim is plain
nonsense.

--
David Portas, SQL Server MVP

Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.

SQL Server Books Online:
http://msdn2.microsoft.com/library/...US,SQL.90).aspx
--|||(chloe.crowder@.bl.uk) writes:
> We received the following in an email from a third-party supplier (who
> naturally has a solution for the problem as described). It sounds like
> gibberish to me, but does anyone have any comments?
><quote>
> SQL in its current incarnation hits a performance brick wall when a
> table contains more than about 75 million rows. This is not a
> configuration limit as the table could be grown a lot larger but the
> performance issue generates problems for ??; primarily during
> search and retrieval of archived objects; although if the database
> engine is being heavily hit for retrieval the archiving process can
> slow down as well.
></quote
SQL [Server] in its current incarnation? Nah, rather the current
incarnation of the application from the supplier hits a brick wall, and
the supplier needs to clean up its act.

OK, a 75-million is no game for kids, and it requires more careful coding
and design than a 750000 row table.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Erland is correct; I personally am running an app that generates
40,000,000 rows of data a day, and it performs well (and it's not a
super server, either). I also suck data out of app by a vendor that
has less than 100,000 rows per day, and it takes hours using their
method.

Not saying you should point the finger at your vendor, but if the
performance of their app is mission-critical, and they value your
business, you need to have a conversation with them about SQL tuning.
Could be something you're doing, or it could be something they're
doing. But it's probably not the engine (unless you're running SQL
Server on a bare-bones server).

Stu|||chloe.crowder@.bl.uk wrote:
> Hi
> We received the following in an email from a third-party supplier (who
> naturally has a solution for the problem as described). It sounds like
> gibberish to me, but does anyone have any comments?
> <quote>
> SQL in its current incarnation hits a performance brick wall when a
> table contains more than about 75 million rows. This is not a
> configuration limit as the table could be grown a lot larger but the
> performance issue generates problems for ??; primarily during
> search and retrieval of archived objects; although if the database
> engine is being heavily hit for retrieval the archiving process can
> slow down as well.
> </quote
Translation 1:

We charge little money for our services, and we need to have profits so
we contract amateurs to do the job and when there are problems we
complain against something/someone not related to us. If you want a
solution pay us more money.

Translation 2:

We didn't think about a table with 75 million rows, we don't want to
look like stupids and lose you as a customer.

etc, etc...

One thing is sure, your supplier is not honest, don't trust them!

> Chloe Crowder
> British Library|||Thanks everyone - I was 99.9% sure it was rubbish and the problem was
with their app, but I thought I should check.

Chloe