Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Write a program
- Thread starter Rjconrep
- Start date
MichaelRed
Programmer
"Can I do this in an Access enviroment?
This is an open item.
"Can this be done this in an Access enviroment?"
Is easily answered. Yes.
As for pointing you in a direction, this depends on a lot of factors, however a few of them are probably 'critical' at the start.
1[tab]Is there a time frame for the effort?
2[tab]What do you know about programming in general?
3[tab]What do you know about relational databases (again generally)?
4[tab]What do you know about Ms. Access (again, generally)?
5[tab]Is this "employer" aware of most/all of the above?
6[tab]Is he (M. Employer) going to support the learning curve? Expense a few books and be patient with the development process?
If the answers to these give you ssome feeling of probable 'success', then:
I would suggest getting one or two 'good books' (one beginner, one intermediate / advanced). M. Employer should be willing to pay up front for these. Otherwise, it is a lost cause.
Get an outline of the business process.
Forget the outline (for the moment).
Read and do ALL of the examples in the beginner's book.
Read the parts regarding RELATIONAL database design again.
Read the parts regarding RELATIONAL database design again.
Do a preliminary table design based on the relational model.
Read the parts regarding RELATIONAL database design again.
Revise your table design to suit.
Start with the intermediate book.
[red]DO NOT EVER USE A MACRO[/red]
Outline your approach with M. Employer. Expect some revisions. DO NOT DISCUSS IMPLEMENTATION DETAILS, this is more-or-less WHAT not WHO, WHEN, WHERE or HOW.
Put as little code as reasonable in forms modules. Most of the code should be (IMHO) regular or general modules.
Implement the process in (small) stages. Do not try to solve the entire problem in a single 'release'.
Be patient. With youself AND with M. Employer AND with the other staff/employees.
MichaelRed
redmsp@erols.com
There is never time to do it right but there is always time to do it over
This is an open item.
"Can this be done this in an Access enviroment?"
Is easily answered. Yes.
As for pointing you in a direction, this depends on a lot of factors, however a few of them are probably 'critical' at the start.
1[tab]Is there a time frame for the effort?
2[tab]What do you know about programming in general?
3[tab]What do you know about relational databases (again generally)?
4[tab]What do you know about Ms. Access (again, generally)?
5[tab]Is this "employer" aware of most/all of the above?
6[tab]Is he (M. Employer) going to support the learning curve? Expense a few books and be patient with the development process?
If the answers to these give you ssome feeling of probable 'success', then:
I would suggest getting one or two 'good books' (one beginner, one intermediate / advanced). M. Employer should be willing to pay up front for these. Otherwise, it is a lost cause.
Get an outline of the business process.
Forget the outline (for the moment).
Read and do ALL of the examples in the beginner's book.
Read the parts regarding RELATIONAL database design again.
Read the parts regarding RELATIONAL database design again.
Do a preliminary table design based on the relational model.
Read the parts regarding RELATIONAL database design again.
Revise your table design to suit.
Start with the intermediate book.
[red]DO NOT EVER USE A MACRO[/red]
Outline your approach with M. Employer. Expect some revisions. DO NOT DISCUSS IMPLEMENTATION DETAILS, this is more-or-less WHAT not WHO, WHEN, WHERE or HOW.
Put as little code as reasonable in forms modules. Most of the code should be (IMHO) regular or general modules.
Implement the process in (small) stages. Do not try to solve the entire problem in a single 'release'.
Be patient. With youself AND with M. Employer AND with the other staff/employees.
MichaelRed
redmsp@erols.com
There is never time to do it right but there is always time to do it over
LonnieJohnson
Programmer
Yes, Access would be a great tool. Since this is rather a large task and you say you have no clue, you may want to start with the Access database wizard.
Open Access and select database wizard and choose from one of the selections. You may want to try two or three and compare. ljprodev@yahoo.com
Professional Development
MS Access Applications
Open Access and select database wizard and choose from one of the selections. You may want to try two or three and compare. ljprodev@yahoo.com
Professional Development
MS Access Applications
- Thread starter
- #4
I have a small amount of programing experience. Right now I use a software called Pres. I write programs that tell our printers what to print on a page. I basicly program variable data letters.
My experience with relational databases are NONE.
I have all of two weeks to write this program so this is time sensitive.
I bought a visual basics book today (visual basic 6 black book) so hopefully this will help me.
If you have anymore input it would appreciated.
My experience with relational databases are NONE.
I have all of two weeks to write this program so this is time sensitive.
I bought a visual basics book today (visual basic 6 black book) so hopefully this will help me.
If you have anymore input it would appreciated.
Sounds like a MIGHTY undertaking. It can be done, but with that amount of time, and your background, I don't know.
As far as books, find the "Access 97 Developer's Handbook" by Getz, Litwin and Gilbert (SYBEX) or the new 2000 version, depending on your version of Access.
As MichaelRed said, start small. First, collect types and examples of all the data you are going to want to track. Decide what data can be derived from other data (Why track total sales when you can add it up on the fly) and remove that. See how the data relates to each other, invoice number, customer id, etc. Start grouping your data together logically, customer info all together, sales data together, employee data together. When you have got that far, repost your groupings (table design) here and we can help some.
After that, you can create your tables in Access. Then, you can start creating forms to display your data and then reports.
Like we are all saying, one step at a time. Hope that is a start...
Terry M. Hoey
th3856@txmail.sbc.com
While I don't mind e-mail messages, please post all questions in these forums for the benefit of all members.
As far as books, find the "Access 97 Developer's Handbook" by Getz, Litwin and Gilbert (SYBEX) or the new 2000 version, depending on your version of Access.
As MichaelRed said, start small. First, collect types and examples of all the data you are going to want to track. Decide what data can be derived from other data (Why track total sales when you can add it up on the fly) and remove that. See how the data relates to each other, invoice number, customer id, etc. Start grouping your data together logically, customer info all together, sales data together, employee data together. When you have got that far, repost your groupings (table design) here and we can help some.
After that, you can create your tables in Access. Then, you can start creating forms to display your data and then reports.
Like we are all saying, one step at a time. Hope that is a start...
Terry M. Hoey
th3856@txmail.sbc.com
While I don't mind e-mail messages, please post all questions in these forums for the benefit of all members.
- Status
Similar threads
- Question