Welcome to SPN

Register and Join the most happening forum of Sikh community & intellectuals from around the world.

Sign Up Now!

Can Crystal Reports be integrated in an Access97 runtime environment?

Discussion in 'Information Technology' started by Tony Ciconte, Jul 28, 2006.

  1. Tony Ciconte

    Tony Ciconte
    Expand Collapse
    Guest

    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
     
  2. Loading...


  3. Larry Linson

    Larry Linson
    Expand Collapse
    Guest

    "Tony Ciconte" <tonyc219@comcast.net> wrote in message
    news:rgeo72lafp6emv6nfjc3m22b45sptsoss4@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
     
  4. aaron.kempf@gmail.com

    aaron.kempf@gmail.com
    Expand Collapse
    Guest

    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
     
  5. Mr B

    Mr B
    Expand Collapse
    Guest

    Re: Can Crystal Reports be integrated in an Access97 runtime envir

    Actually there are some quite valid reasons for doing what this question is
    asking. I can think of at least one very good reason.

    Tony,

    I have had an occasion to talk to Crystal about this and they assure me that
    it is possible to use the reference to the Crystal library and use the
    predefined Crystal reports.

    Also, it is possible to allow users of your application to modify reports,
    provided that they have a copy of Crystal Reports, Standard edition (the
    least expensive version)
    --
    HTH

    Mr B


    "aaron.kempf@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
    >
    >
     
  6. Larry Linson

    Larry Linson
    Expand Collapse
    Guest

    <aaron.kempf@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
     
  7. aaron.kempf@gmail.com

    aaron.kempf@gmail.com
    Expand Collapse
    Guest

    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:
    > <aaron.kempf@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
     
  8. SusanV

    SusanV
    Expand Collapse
    Guest

    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.googlegroups.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:
    >> <aaron.kempf@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

    >
     
  9. Rick Wannall

    Rick Wannall
    Expand Collapse
    Guest

    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.
     
  10. SusanV

    SusanV
    Expand Collapse
    Guest

    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...
    > 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.
     
  11. aaron.kempf@gmail.com

    aaron.kempf@gmail.com
    Expand Collapse
    Guest

    Rick

    you're a paranoid {censored word, do not repeat.}ing 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.
     
  12. Larry Linson

    Larry Linson
    Expand Collapse
    Guest

    <aaron.kempf@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
     
  13. Tim Marshall

    Tim Marshall
    Expand Collapse
    Guest

    aaron.kempf@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
     

Share This Page