Can Crystal Reports be integrated in an Access97 runtime environment?

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

"Tony Ciconte" <tonyc219@comcast.net> wrote in message
news:rgeo72lafp6emv6nfjc3m22b45sptsoss4@4ax.com...[color=blue]
> 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.[/color]

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

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

Hear hear!!

<aaron.kempf@gmail.com> wrote
[color=blue]
> honestly; access has the best reporting
> anywhere; i dont know why in
> the hell you would want to do that.[/color]

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.
[color=blue]
> don't you wish you could subreport like me?
> don't you?
> don't you?[/color]

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

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:[color=blue]
> <aaron.kempf@gmail.com> wrote
>[color=green]
> > honestly; access has the best reporting
> > anywhere; i dont know why in
> > the hell you would want to do that.[/color]
>
> 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.
>[color=green]
> > don't you wish you could subreport like me?
> > don't you?
> > don't you?[/color]
>
> 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[/color]

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

<aaron.kempf@gmail.com> wrote in message
news:1149218186.433651.257370@i39g2000cwa.googlegr oups.com...[color=blue]
> 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:[color=green]
>> <aaron.kempf@gmail.com> wrote
>>[color=darkred]
>> > honestly; access has the best reporting
>> > anywhere; i dont know why in
>> > the hell you would want to do that.[/color]
>>
>> 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.
>>[color=darkred]
>> > don't you wish you could subreport like me?
>> > don't you?
>> > don't you?[/color]
>>
>> 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[/color]
>[/color]

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.

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" <wannall@notadomain.de> wrote in message
news:QeXfg.15334$VE1.12756@newssvr14.news.prodigy. com...[color=blue]
> 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.[/color]

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

"aaron.kempf@gmail.com" <aaron.kempf@gmail.com> wrote:
[color=blue]
>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[/color]

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:[color=blue]
> 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.[/color]

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

-Aaron

Rick Wannall wrote:[color=blue]
> 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.[/color]

<aaron.kempf@gmail.com> wrote
[color=blue]
> 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.[/color]

And, if it made Rick what you describe, what does that make you?
[color=blue]
> What you say here though:[color=green]
>> 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.[/color]
>
> I spit on you and your mothers grave; because
> you are just flat-out wrong.[/color]

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

aaron.kempf@gmail.com wrote:
[color=blue]
> I spit on you and your mothers grave; because[/color]

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