Results 1 to 3 of 3
  1. #1
    Join Date
    Jan 2013

    Unanswered: Access design issues (for a Newbie)

    Could someone please help me with the following issues, before I proceed too far down the path of no return.

    My project is a non-typical database, being essentially an interview form, which collects client data in many fields (500 or so) and then uses that data to produce documents, some that would be quite lengthy. So there won’t be that many records. I have decided to use Microsoft Access 2010.

    1. I haven’t decided whether to have my final application as web-based, or a runtime version. Access requires making the distinction when creating between a “database” or “web-database”. Can I start building my tables, forms, reports in one version, and then convert at a later date? I realize there are functionality features between the two, but it would be nice to make progress, without finding I have to start again if I change my mind.

    2. Document assembly is the purpose of my application. I will create templates in Word, and then pass the “fields” to Word from Access to complete my documents. Mail Merge should accomplish this, although all examples I can find talk about mailing labels and form letters. Would there be any limitations on merging say 200 fields from Access to a 20 page document in Word?

    3. My database is not really relational, but I am subdividing into smaller tables which are logical subsets. I assume there is no problem in having unrelated tables? All database examples I see show relationships between all tables.

    4. I am planning on creating a new record every time a client enters data (I don’t envisage more than 10 concurrent clients, and maybe only 100 over the life of the project), so we are not talking about many records. From what I can read, I should key my tables on autonumber field. I would then need to create a unique timestamp when the user saves the database. Does this mean I need to use a composite key? I need to index on the “client/date saved” parameter to ensure clients can always locate their last valid record. Some help on the right approach here would be appreciated.

    5. My forms require a lot of "help" information, which comes in two types. Basic help with the filling in of the form, and technical details of the subject matter (sometimes many paragraphs). What would be the most professional looking way for doing this - labels inserted within the form, buttons with pop-ups, tool tips?

    Thanks in advance
    Last edited by neilcr117; 02-22-13 at 20:47. Reason: forgot one item

  2. #2
    Join Date
    Jun 2005
    Richmond, Virginia USA
    Provided Answers: 19
    I'll jump on here, since your post has been view 145 times without anyone doing so! The problem, I suspect, is that, like myself, very few, if any, of the experts here use web-based databases, and hence have no experience with them.

    In general terms, though, I can tell you that there really is no native way to 'convert' most of the objects from one type of app to the other. Aside from the differences in functionality that you mentioned, standard databases can utilize VBA code, which I suspect you'll need to interact with Word in the manner you're describing, while web-based databases are limited to using Embedded Macros, which are far less flexible than VBA code.

    I think you're really going to have to bite the bullet, here, and decide which approach you want to take, and stick with it. If it were me, I'd opt for the standard database. The 'web-based' functionality is still in its infancy, as these things go, and while Access works well, over Local Area Networks, one of its biggest weaknesses is that it does not tolerate working over Wide Area Networks, because of the inevitable connection problems that can occur, and the World Wide Web is about as 'wide' and WAN as there is!

    Sorry! Know this is not the answer you wanted.

    Linq ;0)>
    Hope this helps!

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

    All posts/responses based on Access 2003/2007

  3. #3
    Join Date
    Sep 2006
    Surrey, UK
    Provided Answers: 2
    Re point 3 - If you don't relate tables together, outputs from queries based on more than one are monster sets. You end up with a Cartesian product - every record from each table joined to every record in every other table. If your tables are small (single digit record counts), this might be manageable. However, once you have 10 records in one table, 15 in another and 20 in the third, your output will have 10*15*20 = 3000 records in it.
    10% of magic is knowing something that no-one else does. The rest is misdirection.

Posting Permissions

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