Results 1 to 14 of 14
  1. #1
    Join Date
    May 2006
    Posts
    29

    Unanswered: my program in .adp works, but not in .ade

    I'm working on a report generating project, and it works perfectly in .adp. however, after I converted to .ade, it gives me the error:

    "The command you specified is not available in an .mde, .accde, or .ade database"

    Does anyone know how I can fix it? I'm not sure if it is due to DoCmd.OpenReport.

  2. #2
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    What command is it stopping on?

    I've given up on .ADP / .ADE's tbh.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  3. #3
    Join Date
    May 2006
    Posts
    29
    It failed at:
    DoCmd.OpenReport rptName, acViewDesign

    I tried to modify some textboxes control source inside the report, rptName.

    Is it something with ade that I cannot do?I mean modify the design of a report...

  4. #4
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    MDE's & ADE's are runtime files. they do not support design mode.
    so there is no easy way out of your problem


    the only way round I can think of is not to attempt to create the report using a macro. you will need to either design the report, or create it as a new report using code rather than macros (assumig you can do that)
    I'd rather be riding on the Tiger 800 or the Norton

  5. #5
    Join Date
    May 2006
    Posts
    29
    oh...if my program really needs to change the design of a report, is it safe enough that I add a password to protect the vb code, instead of using ade?

  6. #6
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    pchiu,

    I should've thought of that with an mde/ade project and that you're using dynamically created reports (duh - sorry about that.) Good catch healdem.

    An option which I've taken in the past is I had a 2nd mdb (or adp) which had just the reports in it. Not sure if that's an option for you but I wanted to throw it out there as an option. You can though open an mdb/adp passing parameters to it on which macro to run when it opens (for example, I would use parameters to specify which report (macro) to open in my "reporting" mdb which was called from the main data entry mde.) - I used the shell command and also ran a specific macro /x macro - this will help: http://support.microsoft.com/kb/209207)

    Hope that helps.
    Last edited by pkstormy; 08-21-08 at 15:43.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  7. #7
    Join Date
    May 2006
    Posts
    29
    Thanks healdem and pkstormy for the information.

    However, I can't have a 2nd mdb...

  8. #8
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Surely there must be another way of doing what you want without having to modify the report's design at runtime.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  9. #9
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    Ive never tried to create a report on the fly, IVe never seen the need for it. If we ever get close to that then I tend to do a FO report containing all columns, laid out landscape with the tiniest font possible (for one site it was done on A3.. so I do mean a FO big report).

    Generally ou can create the report with one or two redundant columns.

    however I do wonder if the problem here is the use of the macro..... I suspect if the report creation is done using VBA it may well work.
    failing that the other approach may be to deploy the app as a ADP rather than ADE to each users desktop
    I'd rather be riding on the Tiger 800 or the Norton

  10. #10
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Ive never tried to create a report on the fly, IVe never seen the need for it.
    Same.

    I suspect if the report creation is done using VBA it may well work.
    I doubt it tbh.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  11. #11
    Join Date
    Feb 2004
    Location
    Chicago, IL
    Posts
    1,312
    You said you can't have a second database, why? I have a code database where I put all of my common code (string operations, general code). Then in other databases I create a reference to that database. I have not done it with an ADE but I do have an ADP referenced (actually several). You could put the brains of your code in the ADE and have have 'calls' to that code in your ADP with your reports.

  12. #12
    Join Date
    May 2006
    Posts
    29
    I can't have a second database because the user wants only one database. I think the only way I can do is to deploy the app as a ADP, and password protected the vb code. In Access 2007, I can change the Access Option to hide the tables and also disable some default options.(Assuming that the user won't change the Access Option).

    Thanks everyone!

  13. #13
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    If you check out this little example: http://www.dbforums.com/showpost.php...9&postcount=68

    Short of the user opening the mdb using the shift key (which I could've put code in for), the user can't really utilize the top menu or get behind the scenes to see the tables. It's a matter of a "Background" form and then making the other forms "modals" and "popups". Give it a try though.

    I'm not a fan of using the "Disable the Shift Key" method. For me, I'd rather make it an mde (which using the method in the example), I've never had any problems with users getting behind the scenes or into the tables.

    If I find that there's potential for a user to try and get into the mdb (or mde) and bypass the code, that's when I start really securing the most important part (being the tables) down with SQL Server. I also begin to wonder on the intention of such an individual wanting to do so. If they want to fix/update code, then I'll happily show them how to do it and "mark" them as a potential developer and give out my disclaimer should they start dattling with it. Otherwise, if it's a hacker trying to break in for some reason, I might put some other "tracking" methods in to first find out who it is, 2nd, why they are doing it, and 3rd, address it as a concern to the entire IT department of the company (network guys have some neat tools on finding hackers.)

    As an owner of a software development company, when I develop a program for a customer, I happily give them the source code (again, along with my disclaimer should they mess with it, fixing their mistakes will cost them.) And I can almost always tell if someone's been messing with my code. But the company has essentially bought the right to their data (as well as the rights to most of my code with a few exceptions) so if they want to bypass the interface and mess up the data, that's an internal control issue within the company itself that needs to be addressed. I mean, I'm not designing nuclear bombs or anything top secret (even though the data may be) and since I like to keep things simple and easy from a coding prospective (yet extremely functional), I don't really see a need to hide code which can pretty much be gotten from any coding website (except to hide it enough so they don't "accidently" get into it and mess it up.) Hackers intending to do damage "usually" can find a way in if they keep at it long enough and try hard enough (I said "usually"). I've done my fair share of breaking into code JUST so the company could get out the data they needed to get out of their system.

    From my preception, I'd like to see a program I developed enhanced and still used 20 years from now versus being discarded into the trash icon because they couldn't upgrade/tweak it to suit their needs.
    Last edited by pkstormy; 08-26-08 at 15:38.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  14. #14
    Join Date
    May 2006
    Posts
    29
    Thanks for everyone's input!
    After modifying the report_open() method, now my program doesn't need to dynamically generate the report! Just need to update the textbox control source inside the report_open, and it will do the same as my previous dynamic report!

    Now I'm able to generate the ade!

    Thanks again for all the ideas.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •