Results 1 to 6 of 6
  1. #1
    Join Date
    Jun 2010
    Posts
    186

    Unanswered: the Name Game - Access 2007

    After having corrupted code a few times, I've finally pieced together the benefits of front end back end, set it up, put it out to the users, tested it........etc.
    I am still researching design changes, back-ups, compact/repairs, etc....I manage 2 databases myself and want to be sure I'm doing everything correctly

    very confused through all of my googling - Are these references the same? ? ?
    is a front end/back end; accde/accdb and a split database all the same?
    just like 3 feet is a yard?

  2. #2
    Join Date
    Oct 2010
    Posts
    51
    For the most part yes. Accde and Accdb are independent pieces though and are unrelated to back end/front end terminology.

    ACCDB files are unsecured and uncompiled
    ACCDE files are compiled versions of their ACCDB counterpart and therefore cannot have design changes to the forms, queries, and modules.

    I wouldn't think you'd need to have the backend as an ACCDE/MDE. If you need to do a design change to the tables it would force you to return to an older Accdb which may not have the most current data and most likely won't.

  3. #3
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    a split database has a front end and a back end
    the front end contians the user interface (in Access speak thats forms, reports and some queries, and maybe some static or semi static data) the back end is where the data is actually stored.
    in Access speak that will almost certainly be another access file, but it could just as easily be a server SQL engine such as MS SQL Server, MySQL, DB2, Oracle, whatever

    within Access there's numerous file formats, most versions of Access released since it first appeared have had a different file format, until 2007 these were always called MDB's, or when compiled MDE's Office 2007 introduced a new file format with a new file extension ACCDB and its compiled version ACCDE

    the compiled versions have just the code required to make the application run, you cannot make changes to a compiled (MDE or ACCDE version, you can only make changes to a MDB or ACCDE, so its important if you deploy an access application as a compiled version you retain the MDB or ACCDB version to make changes to)

    one of the problems in the Access world is that Access itself isn't a database product, its supposed to be a RAD (rapid Application Development Tool) that can talk to any / many datastore. if you don't specify what you want Access will create that datastore within its own file.

    So a front end and back end equate to a split database
    however an ACCDB is not the same as a ACCDE, an ACCDE is a compiled form of ACCDB, just as MDE is a compiled form of an MDB (the older file extension)

    there was a third native file format ADP or Access Data Project which was more intended to make the separation between the user interface and the datastore more transparent, however it never really took off and was fairly quickly depracated
    I'd rather be riding on the Tiger 800 or the Norton

  4. #4
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Quote Originally Posted by healdem View Post
    I'd rather be riding my Versys
    I've always wondered, with current technology, can you do that, and post here, at the same time?
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  5. #5
    Join Date
    Jun 2010
    Posts
    186
    Thanks for the info.....do you know the better set-up to have for making changes? If a form or report needs modification? A table or query?

    Quote Originally Posted by healdem View Post
    a split database has a front end and a back end
    the front end contians the user interface (in Access speak thats forms, reports and some queries, and maybe some static or semi static data) the back end is where the data is actually stored.
    in Access speak that will almost certainly be another access file, but it could just as easily be a server SQL engine such as MS SQL Server, MySQL, DB2, Oracle, whatever

    within Access there's numerous file formats, most versions of Access released since it first appeared have had a different file format, until 2007 these were always called MDB's, or when compiled MDE's Office 2007 introduced a new file format with a new file extension ACCDB and its compiled version ACCDE

    the compiled versions have just the code required to make the application run, you cannot make changes to a compiled (MDE or ACCDE version, you can only make changes to a MDB or ACCDE, so its important if you deploy an access application as a compiled version you retain the MDB or ACCDB version to make changes to)

    one of the problems in the Access world is that Access itself isn't a database product, its supposed to be a RAD (rapid Application Development Tool) that can talk to any / many datastore. if you don't specify what you want Access will create that datastore within its own file.

    So a front end and back end equate to a split database
    however an ACCDB is not the same as a ACCDE, an ACCDE is a compiled form of ACCDB, just as MDE is a compiled form of an MDB (the older file extension)

    there was a third native file format ADP or Access Data Project which was more intended to make the separation between the user interface and the datastore more transparent, however it never really took off and was fairly quickly depracated

  6. #6
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    a better set up?
    unless the app needs to have design rights then I try to only deploy as a compiled version (MDE or ACCDE) not because Im concerned someone may see how I do things, but because I don't want users tinkering with the application. although Access is nowhere near prone to users ^$^^%$$ things up as Excel there is still that risk.

    sometimes y'just need to deploy as an MDB or ACCDB when you generate a report on the fly.

    if you deploy as a compiled version then you can only develop in an MDB or ACCDB. but if you are developing then you should be using a different environment to the live system. splitting the db helps in this instance
    you have a live app, and live data, development app(s) and data. when you have finished testing you can deploy the app to connect to the live data. Ive always found it essential to have that separation between the developemnt environment and the live system. on some cases I use an intermediate environment which has suitable test data either set up or includes code to write the DDL to create the test cases.

    so y'develop in a MDB or ACCDB ideally talking to whatever datastore you use
    then deploy using whatever Access front end but using a compiled format so users cannot unknowingly tinker with the app.
    I'd rather be riding on the Tiger 800 or the Norton

Posting Permissions

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