Input/Output

[lmcc007]

Input/Output


I’m reading “Selecting the Data” from Running Microsoft Access 2000, pp. 87-94. The confusing part is the input/output explanation. When I think of input I think of typing, keying, or entering raw data into the computer. Output to me is information displayed or printed.

Okay, here is what was printed:

“A data item is an input for a task if you need to read it from the database (but not update it) to perform the task. For example, a customer name and address are some of the inputs needed to create an order. Likewise, data is an output for a task if it is new data that you enter as you perform the task or that the task calculates and stores based on the input data. For example, the quantities of items you enter for an order are outputs; the shipping address and phone number you provide for a new order are outputs as well.”​

The above is confusing me. Can anyone explain it better so this dummy can get it? Thanks!

 

[ajetrumpet]

I have no doubt that the above is confusing you, and I don't agree with it at all. If you want some advice on reading this stuff, and learning database management in general, work as much as you can with other people, weather it be on this site, or at your workplace. A lot of the information that you gather from books, in my opinion, belongs on a shelf in a researcher's lab, not in the business world, because "technical jargon" and "correctness" really don't have much to do with "selling" data, or manipulating it for a purpose.

What drives you should be the reason you're doing it, and for what purpose, not weather you understand what "perfect" logic was used to create the software.

Why are you reading this? Is it required for your job, or are you trying to learn about this stuff? Experience (even on your own time) with the software is the best way to learn any of this, not from a book, although they are good supplements to what experience you can gain. I have no experience, per se, but I can tell you that working with the software and experimenting is the only way you will effectively learn it...

 

[lmcc007]

I'm reading this stuff to learn the correct way. Using wizards usually do not answer the real-world situations. I want to become very good at it so when the opportunity arises again, I will be able to do the job. Also, when you talk to the IT people they're always using these jargons and stuff. I saw one of the analyst creating worksheets and flowcharts on the d/b he was creating for another department. Of course, when you ask questions at work most people or secretive and usually points you to a site or book to read.

 

[ajetrumpet]

Yeah I know.

There are very few people that can handle the balance between the knowledge demand of IT work, and the service demand of people. VERY few. I can't really say anything for sure regarding this, but I would suspect that most IT professionals refer you to books and tutorials because they simply don't want to deal with your lack of knowledge. I'm sure they already have enough to worry about. That is not meant to belittle you, but unfortunately for them, the IT (business) world has become almost as bad as the medical field, in terms of having to cover your a**. Most IT people I have talked to face-to-face seem to be very nervous most of the time, weather its noticeable or not.

But, I can't say I blame them. It is also unfortunate that most information is now stored on machines, and they sit behind locked doors all day long to guard that information.

Noone wants a lawsuit, and I think we all know that people (in general) love to look for ways to start one.

But again, regarding the reading, you can only learn so much from books...just be careful you don't rely to heavily on them. None of us want you to become a machine.

 

[The_Doc_Man]

With respect to Access, you have to be able to open your horizons to disk-based input and output. When you do, you will have less trouble understanding that troubling passage. Remember that input and output can be step-wise. For instance, input can be done to a file first to hold data for a batch-mode operation. Likewise, output can be done to a file first to allow that file to be forwarded via network methods to a printer on another part of your network.

A key to understanding the mess is that Access is not monolithic. You can have tasks (of a sort) inside Access. These tasks would be executed by macros or via button clicks on forms that launch module-based code. Also, using DAO techniques and VB, it is possible to write something outside of Access that uses Access-based data.

In this definition, a task is something to be done regarding data. The data set in question is file-resident rather than a terminal data stream.

Input in this sense occurs when the task needs to see the data.

Output in this sense occurs when the task needs to change the data set.

If you think of Access as just a fancy file, then you are halfway there. If you realize that Access can contain tasks AND files within the same container, you have the whole picture. You just need to be comfortable with it.

 

[lmcc007]

Thanks Doc Man! That's what I'm trying to do--be comfortable with Access like I am Word. That's why I am trying to learn the basic stuff thoroughly.