Did you gain your Access knowledge through books, trial-error/courses....or internet?

  • Thread starter Thread starter Mike375
  • Start date Start date
Ehhhh :

ESL (English as a second language), ESOL (English for speakers of other languages), or EFL (English as a foreign language)
 
Ehhhh :

ESL (English as a second language), ESOL (English for speakers of other languages), or EFL (English as a foreign language)

That really is the irritating thing about the Dutch. Their native language is inaccessible to us but they can speak better English than we can!;)
 
I have a degree in Information Technology where I took 1 Course in Database Systems Design, 2 Courses in MS Access, and 2 Courses in Programming, so I knew all the basics from courses and personal experience with trial and error.

However, for advanced things and correct code syntax I come to this forum, I find this forum to be the best Access forum I've ever found. It's also good to converse with other Database genius's like yourselves every once in a while!

I believe on forums people can build off of each others ideas, someone will post an advanced concept, then someone will take it with "I haven't thought of that... I could also apply that to this!" and then the snowball keeps rolling.

So in short, I feel forums (this forum in particular) is extremely valueble and has taught me a lot!
 
Their native language is inaccessible to us but they can speak better English than we can!;)

In that case, you won't need to access our native language, simply speak
English with us and we'll respond in our own and peculiar way :rolleyes:
Since a while I have a colleque from Scotland here at the office and he's teaching me the Edinburgh morningside dialect ! Big fun ;)

Sorry still off topic
 
Do not think that some of you people who refer to pot luck or trial and error are quite right in what you say.
Len are you suggesting that trial and error is not a valid option.?
It is not unusual to see newbie posters saying "can I.." I always think, well try it and see. I answered a question only 2 days ago on a subject that I had never used before, I just read help, created a test db and tried a few things , finally got the syntax correct and posted

Brian
 
I learned Access and VBA mainly by laziness.

I had jobs to be done and the people who needed the results didn't care how they got the results. So I had a choice between doing the stuff manually or by automating it. Being a lazy b*stard I chose to automate it and learned how to use VBA as a result.

SQL I learnt from a training course and then books and forums.
 
Long ago, I worked for a company that used access for its main datasource and a third party contractor to continually develop it as business expanded. I had the role of being the in-house contact for this contractor. As time wore on, I began to study the code that we were paying for and take on more and more of the work myself inhouse. I've moved on now to .net and SQL Server and only use these forums to bicker. :p
 
Do not think that some of you people who refer to pot luck or trial and error are quite right in what you say.
L
I certainly have learnt from trial and error. If at first it doesn't work then fix it:D

Coming to Acces on top of many years general programming I learned initially from books and the Access helpfiles. With my first copy of Access 97 there was a thick manual which I found very useful
 
Everything I know about Access I learned on this forum. (still learning) I check other sites infrequently, but the level of expertise found here is second to none. Oh, and everything I know about the world I learned on this forum too, from Rich and Col. :D
 
Len are you suggesting that trial and error is not a valid option.?
Brian

Not at all but I think it is important to understand where the trial and error bit actually occurs.

So you have a task to perform, some sort of in depth analysis that you heve never done before then the determination of the process required is not trial and error really it is the disection of the problem and the building of a logical process concept.
Next process it to consider the process concept and resolve this into something more approaching say a chunk of code. At this stage pseudo-english probably with a bit of actual code for variable declaration and loops.

Only now does the trial and error bit maybe start to happen. This is when you are writing say SQL within VB all within various loops. getting the synatx correct can be a bit if a nightmare (for me anyway) and ensuring that the code is actually doing what you intend. Making sure there is not a logical error for instance. Even here the trial and error does involve the logical analysis of the result, be it error message or data.

So Trial and Error does come into the equation but I do not think that the initial analysis, disection, process concept and realisation phases should all be lumped as Trial and Error.

Monkeys (real ones) writing code would produce the result by trial and error eventually (XXXX years). We (most anyway) are capable of very high logical thought processes and these are not trial and error. (in my opinion anyway)

Writing a bit of code to extract data and then determining if this is actually what the user wants is not trial and error. It is the User not specifying what they want which is quite common I have found.

Finally I think that useing a skill to test a scenario is not really trial and error and final finally if we did admit to trial and error then it is not a strong basis from which to debate the next salary increase.

Bit of a ramble bit hope I have explained myself

Len
 
Not at all but I think it is important to understand where the trial and error bit actually occurs.

So you have a task to perform, some sort of in depth analysis that you heve never done before then the determination of the process required is not trial and error really it is the disection of the problem and the building of a logical process concept.
Next process it to consider the process concept and resolve this into something more approaching say a chunk of code. At this stage pseudo-english probably with a bit of actual code for variable declaration and loops.

Only now does the trial and error bit maybe start to happen. This is when you are writing say SQL within VB all within various loops. getting the synatx correct can be a bit if a nightmare (for me anyway) and ensuring that the code is actually doing what you intend. Making sure there is not a logical error for instance. Even here the trial and error does involve the logical analysis of the result, be it error message or data.

So Trial and Error does come into the equation but I do not think that the initial analysis, disection, process concept and realisation phases should all be lumped as Trial and Error.

Monkeys (real ones) writing code would produce the result by trial and error eventually (XXXX years). We (most anyway) are capable of very high logical thought processes and these are not trial and error. (in my opinion anyway)

Writing a bit of code to extract data and then determining if this is actually what the user wants is not trial and error. It is the User not specifying what they want which is quite common I have found.

Finally I think that useing a skill to test a scenario is not really trial and error and final finally if we did admit to trial and error then it is not a strong basis from which to debate the next salary increase.

Bit of a ramble bit hope I have explained myself

Len

No please explain yourself:D
 
if we did admit to trial and error then it is not a strong basis from which to debate the next salary increase

I especially liked that bit! :)
 
No please explain yourself:D


So you have a task to perform, some sort of in depth analysis that you heve never done before then the determination of the process required is not trial and error really it is the disection of the problem and the building of a logical process concept.
Next process it to consider the process concept and resolve this into something more approaching say a chunk of code. At this stage pseudo-english probably with a bit of actual code for variable declaration and loops.

Only now does the trial and error bit maybe start to happen. This is when you are writing say SQL within VB all within various loops. getting the synatx correct can be a bit if a nightmare (for me anyway) and ensuring that the code is actually doing what you intend. Making sure there is not a logical error for instance. Even here the trial and error does involve the logical analysis of the result, be it error message or data.

So Trial and Error does come into the equation but I do not think that the initial analysis, disection, process concept and realisation phases should all be lumped as Trial and Error.

Monkeys (real ones) writing code would produce the result by trial and error eventually (XXXX years). We (most anyway) are capable of very high logical thought processes and these are not trial and error. (in my opinion anyway)

Writing a bit of code to extract data and then determining if this is actually what the user wants is not trial and error. It is the User not specifying what they want which is quite common I have found.

Finally I think that useing a skill to test a scenario is not really trial and error and final finally if we did admit to trial and error then it is not a strong basis from which to debate the next salary increase.

How's that

Len :D:D:D:D:D
 

Users who are viewing this thread

Back
Top Bottom