Can Crystal Reports be integrated in an Access97 runtime environment?

[Tony Ciconte]

We are evaluating the prospect of integrating and/or using Crystal
Reports with some of our current products. Some of these are still in
Access 97 and are running well. Since we cannot include the report
wizard in a runtime environment, we are looking at ad hoc report
writers like Crystal.

Can we include Crystal with our runtimes and/or is there another
report writer that we should be looking at? Any and all help is
greatly appreciated.

TC

[Larry Linson]

"Tony Ciconte" <to******@comcast.net> wrote in message
news:rg********************************@4ax.com...

We are evaluating the prospect of integrating and/or using Crystal
Reports with some of our current products. Some of these are still in
Access 97 and are running well. Since we cannot include the report
wizard in a runtime environment, we are looking at ad hoc report
writers like Crystal.

Can we include Crystal with our runtimes and/or is there another
report writer that we should be looking at? Any and all help is
greatly appreciated.

Especially as you are still deciding on a Report Writer, this seems an
excellent question to ask the manufacturer of Crystal Reports. It may depend
on how you have your runtimes set up, security, etc., but the Crystal
Reports folks would be the ones who should have the information.

Larry Linson
Microsoft Access MVP

[aaron.kempf]

honestly; access has the best reporting anywhere; i dont know why in
the hell you would want to do that.

don't you wish you could subreport like me?
don't you?
don't you?

-Aaron

[w_a_n_n_a_l_l_ -]

Hear hear!!

[Larry Linson]

<aa*********@gmail.com> wrote

honestly; access has the best reporting
anywhere; i dont know why in
the hell you would want to do that.
I agree with you that Access has the best reporting I have found in any
software product. But, that was not the question that the O.P. asked.
don't you wish you could subreport like me?
don't you?
don't you?

I don't know because I haven't seen any of your Subreports, but because the
only reporting mechanism I use is Access Reports, I do use Subreports when
appropriate.

Larry Linson
Microsoft Access MVP

[aaron.kempf]

crystal can only subreport one level deep

or something ridiculous like that

i ran into it a ton; when i was converting mdb-> crystal reports; about
100 reports in a month about 4 years ago

-aaron
Larry Linson wrote:

<aa*********@gmail.com> wrote

> honestly; access has the best reporting
> anywhere; i dont know why in
> the hell you would want to do that.

I agree with you that Access has the best reporting I have found in any
software product. But, that was not the question that the O.P. asked.

> don't you wish you could subreport like me?
> don't you?
> don't you?

I don't know because I haven't seen any of your Subreports, but because the
only reporting mechanism I use is Access Reports, I do use Subreports when
appropriate.

Larry Linson
Microsoft Access MVP

[SusanV]

How do you allow users to create reports (create = design new) when
deploying MDE's? IIRC, that was the OP's original problem, and I'd love to
get around it myself...

SusanV

<aa*********@gmail.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...

crystal can only subreport one level deep

or something ridiculous like that

i ran into it a ton; when i was converting mdb-> crystal reports; about
100 reports in a month about 4 years ago

-aaron
Larry Linson wrote:

<aa*********@gmail.com> wrote

> honestly; access has the best reporting
> anywhere; i dont know why in
> the hell you would want to do that.

I agree with you that Access has the best reporting I have found in any
software product. But, that was not the question that the O.P. asked.

> don't you wish you could subreport like me?
> don't you?
> don't you?

I don't know because I haven't seen any of your Subreports, but because
the
only reporting mechanism I use is Access Reports, I do use Subreports
when
appropriate.

Larry Linson
Microsoft Access MVP

[Rick Wannall]

Simple answer: You don't create reports in an MDE. Not the developer, not
the user, not anybody.

That's a good thing, bacause you should never, ever let users create objects
in any live application object or have direct access to data stores.

I saw a post, perhaps in another chain, that offered the correct answer:
With the MDE, distribute an MDB and let users create reports in that MDB.
You must use an MDB if you want to create a form, a report, or any kind of
module.

There are ways to look into the MDB from the main app and run reports from
there. You'll have an issue of deciding whether you can replace the mdb at
will (almost certainly not) and what to do if you must replace it (e.g.,
import existing reports). If properly planned you can probably avoid having
to have much to do with the external MDB.

The moment you go this route, you have a problem of controling how users get
to data.

Worst idea: Just link to all the underlying tables you need and let users
work from that. Very hard to control anything about data access in this
arrangement.

Slightly better: Don't link to anything from the MDB. Create queries that
present the kind of data from which users can easily make reports, and fully
qualify the tables in the FROM clause with the path/mdbname/tablename. You
can't hide them, and unless you're using Access security you can't keep
users from opening them up to look at the SQL.

Much better: You may not be up for this level of additional effort, but the
best way to allow users to create reports generally, regardless of the tool
really, is to create a data warehouse. Basically you would use queries such
as described above (user-oriented data presentation) without having to
expose them to the users.

You get the users to work with you to define what sort of data presentations
they need to see in order to make reports. You create those queries. You
export the data they retrieve on some periodic basis (daily is a good start)
to a data warehouse. That external MDB is the data warehouse.

You make this contract with your users: I (developer) control the tables
that exist over there. The will be replaced regularly with fresh data. You
(users) can create queries, reports, forms, anything you like. Remember
that the data you're looking at is a data warehouse. Do not perform data
entry there. Use the app for data entry. Use the warehouse for ad hoc
reporting. What you'll find is that with time you will discover reports
that you can and should incorporate into the application.

They get to create reports and anything else they like. You retain control
of data access. You leven get some very knowledgeable users creating
reports that will improve the utility of the application. Win, win, win.

[SusanV]

Wow, excellent response! That's what I thought - no way around it for MDE,
and they are NOT getting an MDB - too many problems in the past with things
being altered or deleted. Your other suggestions sound interesting, but are
far too labor intensive for the minimal advantages returned, at least in
this case. Being as I'm in-house, when users need new reports I do the
design for them, then redistribute the MDE frontend, and that's working for
us.

Thanks, Rick, for taking the time to lay that all out so clearly

SusanV

"Rick Wannall" <wa*****@notadomain.de> wrote in message
news:Qe*******************@newssvr14.news.prodigy. com...

Simple answer: You don't create reports in an MDE. Not the developer,
not
the user, not anybody.

That's a good thing, bacause you should never, ever let users create
objects
in any live application object or have direct access to data stores.

I saw a post, perhaps in another chain, that offered the correct answer:
With the MDE, distribute an MDB and let users create reports in that MDB.
You must use an MDB if you want to create a form, a report, or any kind of
module.

There are ways to look into the MDB from the main app and run reports from
there. You'll have an issue of deciding whether you can replace the mdb
at
will (almost certainly not) and what to do if you must replace it (e.g.,
import existing reports). If properly planned you can probably avoid
having
to have much to do with the external MDB.

The moment you go this route, you have a problem of controling how users
get
to data.

Worst idea: Just link to all the underlying tables you need and let users
work from that. Very hard to control anything about data access in this
arrangement.

Slightly better: Don't link to anything from the MDB. Create queries
that
present the kind of data from which users can easily make reports, and
fully
qualify the tables in the FROM clause with the path/mdbname/tablename.
You
can't hide them, and unless you're using Access security you can't keep
users from opening them up to look at the SQL.

Much better: You may not be up for this level of additional effort, but
the
best way to allow users to create reports generally, regardless of the
tool
really, is to create a data warehouse. Basically you would use queries
such
as described above (user-oriented data presentation) without having to
expose them to the users.

You get the users to work with you to define what sort of data
presentations
they need to see in order to make reports. You create those queries. You
export the data they retrieve on some periodic basis (daily is a good
start)
to a data warehouse. That external MDB is the data warehouse.

You make this contract with your users: I (developer) control the tables
that exist over there. The will be replaced regularly with fresh data.
You
(users) can create queries, reports, forms, anything you like. Remember
that the data you're looking at is a data warehouse. Do not perform data
entry there. Use the app for data entry. Use the warehouse for ad hoc
reporting. What you'll find is that with time you will discover reports
that you can and should incorporate into the application.

They get to create reports and anything else they like. You retain
control
of data access. You leven get some very knowledgeable users creating
reports that will improve the utility of the application. Win, win, win.

[Tony Ciconte]

Aaron,

As i mentioned in my original email, I am distributing a runtime. You
cannot include the report wizards with runtimes and that is why I
cannot use the Access report writer.

JM

"aa*********@gmail.com" <aa*********@gmail.com> wrote:

honestly; access has the best reporting anywhere; i dont know why in
the hell you would want to do that.

don't you wish you could subreport like me?
don't you?
don't you?

-Aaron

[aaron.kempf]

Rick

you're a paranoid fucking retard and you should learn how to use access
before talking shit.

wait a second.

I agree with what you're saying for data warehouses.

What you say here though:

That's a good thing, bacause you should never, ever let users create objects
in any live application object or have direct access to data stores.

I spit on you and your mothers grave; because you are just flat-out
wrong.

-Aaron

Rick Wannall wrote: Simple answer: You don't create reports in an MDE. Not the developer, not
the user, not anybody.

That's a good thing, bacause you should never, ever let users create objects
in any live application object or have direct access to data stores.

I saw a post, perhaps in another chain, that offered the correct answer:
With the MDE, distribute an MDB and let users create reports in that MDB.
You must use an MDB if you want to create a form, a report, or any kind of
module.

There are ways to look into the MDB from the main app and run reports from
there. You'll have an issue of deciding whether you can replace the mdb at
will (almost certainly not) and what to do if you must replace it (e.g.,
import existing reports). If properly planned you can probably avoid having
to have much to do with the external MDB.

The moment you go this route, you have a problem of controling how users get
to data.

Worst idea: Just link to all the underlying tables you need and let users
work from that. Very hard to control anything about data access in this
arrangement.

Slightly better: Don't link to anything from the MDB. Create queries that
present the kind of data from which users can easily make reports, and fully
qualify the tables in the FROM clause with the path/mdbname/tablename. You
can't hide them, and unless you're using Access security you can't keep
users from opening them up to look at the SQL.

Much better: You may not be up for this level of additional effort, but the
best way to allow users to create reports generally, regardless of the tool
really, is to create a data warehouse. Basically you would use queries such
as described above (user-oriented data presentation) without having to
expose them to the users.

You get the users to work with you to define what sort of data presentations
they need to see in order to make reports. You create those queries. You
export the data they retrieve on some periodic basis (daily is a good start)
to a data warehouse. That external MDB is the data warehouse.

You make this contract with your users: I (developer) control the tables
that exist over there. The will be replaced regularly with fresh data. You
(users) can create queries, reports, forms, anything you like. Remember
that the data you're looking at is a data warehouse. Do not perform data
entry there. Use the app for data entry. Use the warehouse for ad hoc
reporting. What you'll find is that with time you will discover reports
that you can and should incorporate into the application.

They get to create reports and anything else they like. You retain control
of data access. You leven get some very knowledgeable users creating
reports that will improve the utility of the application. Win, win, win.

[Larry Linson]

<aa*********@gmail.com> wrote

you're a paranoid f***ing retard and you
should learn how to use access before
talking s**t.

wait a second.

I agree with what you're saying for data warehouses.
And, if it made Rick what you describe, what does that make you?
What you say here though:

That's a good thing, bacause you should never,
ever let users create objects in any live appli-
cation object or have direct access to data stores.

I spit on you and your mothers grave; because
you are just flat-out wrong.

The drive-by poster strikes again, assuring that whatever he's aiming for,
he'll be _spitting into the wind_ with whatever he may have to offer here.

Larry Linson
Microsoft Access MVP

[Tim Marshall]

aa*********@gmail.com wrote:

I spit on you and your mothers grave; because

Ummm, I must be missing something. What did this guy do to provoke such
a reaction?

Do you swat flies with an artillery barrage instead of a flyswatter?

Good heavens...
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me