A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » New Users
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Tables used during development



 
 
Thread Tools Display Modes
  #1  
Old June 21st, 2004, 06:55 PM
rpw
external usenet poster
 
Posts: n/a
Default Tables used during development

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
  #2  
Old June 21st, 2004, 08:04 PM
medialint
external usenet poster
 
Posts: n/a
Default Tables used during development

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

  #3  
Old June 21st, 2004, 10:01 PM
rpw
external usenet poster
 
Posts: n/a
Default Tables used during development

Thanks for responding.

I was hoping to learn specifics - I usually don't do too well without specifics. I'm gussing that you use "zSys_" at the beginning of each table so that a) they are listed at the bottom of the db window, and b) you recognize the tables as your development tables and not part of the db app itself. Or do you have other/more/different reasons?

For the TaskList table - what's the field structure of that, do you have a form that you use for updating the table, do you have a standard list of tasks that is the start point for each app, if so what are those tasks, do you copy a master task table into each new app, could you email a copy to me?

For the Settings table, this holds all of the settings for all of the forms, reports, and controls, or what?

If there's a book, a link, or a download, (that describes some of these good developer conventions/habits) that you can direct me to, that'd be great.

thanks again,

--
rpw


"medialint" wrote:

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

  #4  
Old June 28th, 2004, 09:52 PM
Rohn
external usenet poster
 
Posts: n/a
Default Tables used during development

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


  #5  
Old June 29th, 2004, 05:41 PM
rpw
external usenet poster
 
Posts: n/a
Default Tables used during development

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


  #6  
Old June 30th, 2004, 10:39 PM
Rohn
external usenet poster
 
Posts: n/a
Default Tables used during development

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



  #7  
Old July 1st, 2004, 01:29 AM
rpw
external usenet poster
 
Posts: n/a
Default Tables used during development

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


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 02:16 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.