Page 1 of 2 12 LastLast
Results 1 to 15 of 16
  1. #1
    Join Date
    Apr 2004
    Posts
    6

    Unanswered: Creating applications

    Dear All,

    Please could you provide some pointers on how to go about creating an Access based application. I've constructed the database but haven't the slightest idea about how to begin converting this into an disributable application??

    Any advice would be much appreciated.

    Regards,

    Iwan

  2. #2
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    GAh...

    Buy a book.

    Seriously.

  3. #3
    Join Date
    Apr 2004
    Location
    outside the rim
    Posts
    1,011
    I would have to agree - get a book, or find a local expert.

    There are so many little things, like "client/server" and "front end/back end" and the large list of issues you have to contend with working through the mystery and frustration of Microsoft's "record-locking" just to name a few.

    You also have to consider your target audience - are they wizards, or do you need to shield them from actually using Access and present them with a nice, easy, "Windows" interface?

    You may want to consider hiring somebody if it is for business purposes.

    Good luck!

  4. #4
    Join Date
    Apr 2004
    Posts
    6
    Thanks,
    That was sort of what I was after, the name of any books etc that would give guidance on how to do this. All I want really is to be able to supply the database on a disk but to have a 'mock' installation process that would just transfer the files into the program directory and add a short cut to the desktop. I've been told you can do this by writing a batch code through Ms-DOS but being a novice this is something I wouldn't even begin to knowhow to do. I guess without the kind of funding to employ the services of a programmer, it's back to trawling the internet for tips! Cheers for your time anyway though.
    Regards,
    Iwan

  5. #5
    Join Date
    Jan 2004
    Posts
    75
    I use something like the following to send to my users to install the front end. Paste it in notebook, make appropriate changes, save it with a .bat extension. Viola.


    ECHO OFF
    color 2f
    net use g: \\123.456.7.890\Location
    ECHO SYSTEM ERROR 85 IS NORMAL PLEASE WAIT
    ECHO .
    ECHO .
    md c:\databaseapp
    ECHO .
    ECHO .
    ECHO STILL LOADING PLEASE WAIT
    ECHO .
    COPY g:\location\app.mde C:\databaseapp
    COPY g:\ftc\master\app.lnk c:\windows\desktop
    ECHO .
    ECHO .
    ECHO .
    ECHO UPDATE COMPLETE
    ECHO PRESS ANY KEY TO EXIT
    PAUSE
    ECHO ON

  6. #6
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Originally posted by Iwan10_Novice
    Thanks,
    That was sort of what I was after, the name of any books etc that would give guidance on how to do this. All I want really is to be able to supply the database on a disk but to have a 'mock' installation process that would just transfer the files into the program directory and add a short cut to the desktop. I've been told you can do this by writing a batch code through Ms-DOS but being a novice this is something I wouldn't even begin to knowhow to do. I guess without the kind of funding to employ the services of a programmer, it's back to trawling the internet for tips! Cheers for your time anyway though.
    Regards,
    Iwan
    That one is a bit easier to field.



    The poster above me is right on the mark. I also use a similar method to control rolling out new versions of my front end.

    I use a small update .exe program coded in delphi that essentially issues commands to the "dos" command shell (it's not really dos anymore, but meh). The in the OnLoad procedures for my main forms, I have code that will check the last modified date of the "master" copy on the server, and the current "client" installed on the users machine. If the master is newer, I prompt the user to run the update executable and kill the application.

    I did have this automated for a while by monitoring windows messages from my update.exe and waiting for the client copy to close, then executing the batch file.

  7. #7
    Join Date
    Apr 2004
    Posts
    6
    sublimsos/Teddy,
    That's great thanks a lot for your help but please could you help with a few more questions, sorry if they seem pretty basic!
    -Using the coding you've supplied, all I need to do is insert the location where they're stored on my hard drive?
    -If this is the case and I'm wanting to supply people my database from CD, would it be just a matter of burning this bat file to the CD and this is what people would use to install the database on their computer or would it not install because the database is situated on my own computer (hope that makes sense!).
    -Also, it's not overly important but is it theoretically possible to extend this coding to add a message saying where the database is to be installed and asking whether the person wants to continue (giving a yes/no option)?
    -Finally, in your opinion, I realise this wouldn't be a conventional installation but do you think it would suffice as a method of distributing a database?
    Many thanks to you both for your help once again and sorry again if I must sound too ignorant!!
    Kind Regards,
    Iwan

  8. #8
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Those questions cannot be effectively answered until you have a firm model of the client-server relationship.

    Are you talking about distributing a whole database, or distributing a front end?

    If it's a front end, is it a front end to a sql server or another access db?

    Where is the server located?

  9. #9
    Join Date
    Apr 2004
    Posts
    6
    My database is based around the main database table, a form and a report. I plan to add a switchboard and security to prevent its structure etc being altered. Sorry for having to turn the question round but essentially I just want to distribute these components without people being able to alter them (except obviously to add records and print them as reports etc.) so I'm unsure whether I'd need to distribute it as a front end package or the whole database? I'm quite happy for people to have the database as I'll be distributing it specifying that there is a software requirement for Access 2000 upwards.
    Thanks again for your patience.
    Iwan

  10. #10
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    You're missing A LOT of information.

    Does the data need to be centralized? Does information edited or inserted by one user need to be available to another? Are there security constraints?

    I'm sorry, but ti seems like you really don't have any model of what you'd like to do at all. I don't think we can help you much.

  11. #11
    Join Date
    Nov 2003
    Location
    San Francisco, CA USA
    Posts
    59
    Start with this:

    Lookup or read about the following:
    splitting the database into a front-end and back-end (from the clues in your messages - you want to do it)
    learn how to create an MDE file from your front-end database
    search the web for fundamentals of creating batch files **

    Lastly, I think you're in over your head. You may have to get some help or lower your expectations.

    Magee


    ** bad news: unless you are willing to buy a tool or use VB or something else to write an installation routine, you're going to have to make some decisions about where stuff goes and hard-code them into your batch file. It's easy to create a C:\access directory to copy the MDE file locally, but you don't have discretion over their network server drive mappings. Consequently, you won't be able to write a batch file to install the back-end somewhere appropriate. Hope you're up to speed on your documentation/technical writing skills!!

  12. #12
    Join Date
    Oct 2003
    Posts
    706
    The Developer edition of Access includes tools and docs that specifically concern how you can (theoretically) distribute an application based on Access to someone who does not have a copy of that product.

    But ... let's be realistic, shall we?

    If someone's seriously interested in using your application, simply tell them that your app requires that they must have at least thus-and-such version of Access already installed on their computer. Then they simply open the .MDB file you gave them, and use it. Period. End of story.

    Access is a very huge product, with all kinds of nasty links into other parts of the Windows system that happen to work beautifully if you have run Microsoft's installers to put the real, honest-to-jeezus Access product on your computer. It's a hot-rock comin' straight out of Hell if you don't. The simplest solution is also the most obvious: require them to buy a copy of Access and put it on before they use your program.

    This is the voice of experience talking. I've used Access since good ol' release 1.0. (Weelll... it wasn't that "good" but it definitely was "ol'.")
    ChimneySweep(R): fast, automatic
    table repair at a click of the
    mouse! http://www.sundialservices.com

  13. #13
    Join Date
    Apr 2004
    Posts
    6
    Thanks to you all for your replies once again.
    Teddy, Mageem, Sundial, thanks for your advice, you've pretty much confirmed what I've been trying to ask (albeit maybe badly). This is the situation:
    I have a database I want to distribute. I willbe specifying that to run it people will need Access version 2000 or newer. I realise developing it as a professional standalone application is well beyond my capability. Therefore, what I wanted to do was to distribute it as an mdb (mde?) file as you suggested. However, what I was trying to estblish is, could you realistically expect to provide a mdb database file as a commercial application? This is why I wanted to use a kind of pseudo installation process using the .bat file (as discussed earlier) to give it at least an air of professionalism! Have you successfully distributed applications as mdb files or in your experience have the end users expected a bit more e.g. proper installation process, flashy icon graphics etc?
    All I want people to be able to do with it is enter data in a form, the form store the info in a table and from the form, enable the user to print off a report (which it currently does) but not to be able to alter any of the format (guessing this is probably the back end). It is intended to be used by one central computer that stores all the info. I'm not worried about servers etc or the need to be used by more than one terminal in a workplace and updating tables etc, as all the info will be stored on a central user's computer as if a privte user wa using it at home. So, what I want to do is add some security, a switchboard, change the icon (if poss) and get rid of some of the tool bars, write some instructions and then distribute copies of this final database file!
    Thanks again,
    Iwan

  14. #14
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Originally posted by Iwan10_Novice
    It is intended to be used by one central computer that stores all the info. I'm not worried about servers etc or the need to be used by more than one terminal in a workplace and updating tables etc, as all the info will be stored on a central user's computer as if a privte user wa using it at home.
    Iwan
    "used by one central computer that stores all the info" and "users computer as if a private user was using it at home" is two completely different tasks...

    If you could please clarify your expectation.

    Do you wish to have information that is entered by a given user available to everyone else?

    Also, you are far to concerned regarding the appearance of your installation routine.

    The "swank" factor should be an afterthought to your process. Make it work first, worry about graphics later.

    Just for reference, I don't use any splash-screens etc for my installation an update programs. Just a status bar and button. Keep it simple.

  15. #15
    Join Date
    Apr 2004
    Location
    outside the rim
    Posts
    1,011
    It sounds like you have a program and somebody else wants to use it (definition of the win-win consulting gig).

    For some basic info on “Distributing” your software, I have some info below. On the topic of “Front-End/Back-End”, sharing, multi-user, etc. search this forum as there are some really good discussions on the topic.

    In a very basic sense, if your requirement is that users have Access 2000 or newer, and you are going to distribute the MDE OR the MDB, then "installation" is a simple as:

    a) put the "front-end" on their PC and create a shortcut to it
    - or -
    b) put the "front-end" in a shared drive and create a shortcut to it

    You can change the ICON of the shortcut. You can add the command line option “/nostartup” to eliminate the Access splash screen.

    There is a way to actually “install” an Access based application, but it's not required to meet the goal as stated. If Access is installed, then Windows will launch Access when the shortcut is clicked (similar to double-clicking an XLS file will launch Excel and then open the file). What you will want is a “startup” form – the form that opens when the file is opened. This can be set by clicking “Startup” under the “Tools” menu. If you need to get in and bypass the “Startup form”, hold down the shift key while opening the file. Read through the options carefully, and consult the help files frequently. MSDN.Microsoft.com is also a good resource.

    The MDE will give you more security and less flexibility for the users (often the case with software development). The MDE does not allow you to edit forms, reports, macros, code and I don’t think queries either. MDE also defaults with far fewer menu items. So, in a nutshell, MDE protects your “software” from tampering. Unfortunately, MDE does NOT provide any security for the data itself, which anybody with the full install can get too even in an MDE (our thanks to Microsoft).

    The task of "installation" and MDE's is for user's who do not have Access installed. This is in the realm of "software licenses" – as technically a license is required for each user that has Access installed on their PC. For companies that do not want to have the full installation of Access on each user’s PC (there are many reasons, not just $$) Microsoft gives the “Run-Time” option, which requires installation on the host PC (for at least the first Run-Time application – subsequent home-grown access applications will run providing the shortcut specifies the Access.exe program file). This is where the MDE comes in. Access “Run-Time” is a watered down installation of Access that can run MDE’s. An MDE is simply a “Pre-Compiled” version of the MDB and does not have form and report editing capabilities. For “Run-Time” to work, you MUST have predefined forms and reports because it will not let you go into design mode, nor will it give you the standard Access interface (just like MDE’s). Access “Run-Time” does not require purchased licenses (the assumption is that somebody with a licensed version has to create the software and maintain the back end).

    “Run-Time” and MDE are related, but do not travel together. “Run-Time” is a type of Access installation and will open both MDE and MDB, but will do nothing unless a Startup form is specified. “Full-Install” will also open both and default to the Startup form, but will not let you do anything to the structure of an MDE (you’ll notice you can open objects in design mode, but you can’t save).

    Confused? Don’t worry – you’re not alone on this one. Try the Microsoft knowledgebase as a start for MDEs and Run-Time for some more detailed information.

    Good luck and have fun!

Posting Permissions

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