Hi Rohn,

Keeping track of the modifications is another great idea for a developer to use. I've been trying to teach myself Access (with the help of this ng and alot of books) since January. Your tip, the ToDo table - they both seem like good things to implement from the beginning if one is to be professional in his db development.

I've just signed up for the AccessVBNetSQL magazine. Lots of handy little tips in there too. I guess in a few years (8-10?), if no one else has written a book on good Access developer habits, I will (after I learn enough of 'em, eh?).

Thanks for sharing, I appreciate it.
--
rpw


"Rohn" wrote:

I just assumed that medialint would clarify his use of those tables..... And I thought I would share my own naming conventions, if they would help someone!

btw, I do use some of medialint's tools. I create, in every application I develop, a table structure that I use to track all of the decisions, changes, dates, and approvals of the changes that the database goes through from inception to the current revision. Generally, these tables/queries do not take up much space, but do provide great record retention and insight over the course of time though development stages.

For one user, I developed a table with lists the Reports and definition of the reports available within the db. The same with Queries, Forms, and Tables. I did this on the request of the users, so that they have a general idea of what is in the db and how things are linked.

Example, I have one project with a table with 240 records of all the changes and modifications that have been made to the db. I know, not very elaborate but I do have clear path of everything that has been done to the db.
_____
Rohn Everson
(712) 548-6900 (cell)
UOP email:
Yahoo messenger:

"rpw" wrote in message ...
Hi Rohn,

Thanks for taking the time to respond to this, and thank you for sharing your naming conventions. I'v adopted the standard naming conventions that can be found in most Access/VBA books.

But aside from that, I wasn't asking about naming conventions, I was asking about the details of the tables Duane Hookom had listed - how and why they are used as a standard part of any project he's building.

Some of the things are obvious, eg. tblToDo - it's a task list of things to do. But what's not so obvious (to me) is how the fields are setup, the types of tasks that are in the list - are they specific to this project, or is there a list of generic tasks, or both?, is there a form that is used for modifying the information or is it entered in the table directly?

Or for example the tables relating to reports. Why store reports and report criteria in tables? Is there a way of having a report refer to the table to get the latest version of report criteria? How is that done, what is the advantage over simply modifying the report?

If a person aspires to becoming a good Access developer, then there are probably some things that a good developer should do/know in addition to building tables, queries, forms, and reports, and using VBA. The listing of tables he posted hinted that he's got some good habits developed. I have scanned the books that I own, but I don't find anything that describes (as a chapter or topic) those types of developer "secrets".

Maybe it's just personal habits, like medialint suggested, and after years of developing projects you just sorta 'know' these things. I guess that I was really hoping that if I couldn't get details here, there might be a book available.

If there isn't a book available, then maybe someone who knows this stuff could write one - you know something like "Developing Good Developer Habits - Insider Information on How to Build Projects Effectively and Efficiently"

Thanks for letting me rant on....

--
rpw


"Rohn" wrote:

Good, Bad, or Indifferent....... I use key letters at the beginning of every form, table, query, report:
(this helps me see the connections. Later, it helps me see if Forms or Reports are built off of Queries or Tables.) Maybe more advanced user/developers have a better approach?

Table:
(T)EmployeeCore
(T)Employee_Data
(T)Perf_App
(T)Attend
(T)Benefits
(T)EEOC

Query:
(Q)Employee_Data
(Q)EmployeeSearch_Tenure
(Q)EmployeeSearch_Dates
(Q)Attend_CrossTab
(Q)Attend_SnapShot
(Q)EEOC

Form: (DE=Date Entry)
(F)Employee_DE
(F)Perf_App_DE
(F)Attend_DE

Report:
(R)EmployeeSearch_Dates
(R)EmployeeSearch_Tenure
(R)Attend_Overview

_____
Rohn Everson


"medialint" wrote in message ...
Sounds like a personal convention. Conventions are good. I think he was just describing some coding habits. I do similar, in Access I normally start all my app specific tables zSys_

And much the same
zSys_Settings
zSys_Reports
zSys_TaskList

etc.

Sounds like the point was to document and put common programming parameters into tables (rather than hardcoding).


"rpw" wrote:

Hi,

Duane Hookom had posted this in another thread and I'd like to know if there could be some expanded explanations, table structure, how to use it, etc. (or point to a link or book that describes these).

You may have some temporary tables in the front end. Also, I keep tables:
tblAppVersion - version number and date of last update
tblReports - table of all the reports used in the application
tblCriteria - all possible criteria used in reports
tblReportCriteria - table that identifies which criteria are used with
which report
tblTables - list of tables that require linking and which back end
tblToDo - list of tasks to be completed in the application

Thanks in advance!
--
rpw