Data buffers

TomBascom

Curmudgeon
A buffer name is what you type in your 4GL code
–A buffer is a pointer to an instance of a database record.
–The default buffer name for every table is the plain old table name.
–Named buffers are: define buffer bufferName for tableName.

Within a session:
–Multiple buffers can be simultaneously defined for a table.
–Each buffer can point to a different instances of records in that table.
–Multiple buffers can point to the same instance of a record:
•but there is only ever one instance of a particular record.
•a particular record can only have ONE lock state.
 
The question is what are called data buffers and how many types of data buffers (what are they) are used in progress.

What you explained looks as though they all point to record buffer which we are referencing using explicit buffer names if necessary. Hence, as an answer to the question, I thought record buffer is the only data buffer in progress? If this is not right, please can you explain? Thanks
 

TomBascom

Curmudgeon
That could be. But "data buffers" is an awkward phrasing and that makes me wonder if the person asking the question is possibly asking about some other concept.

If we are in fact talking about buffers as in "DEFINE BUFFER ..." then there are concepts related to the default buffer (or the unnamed buffer), named buffers, borrowed buffers, shared buffers, static buffers, dynamic buffers and probably a few others that I am forgetting. One or more of those concepts might be related to what the questioner means by "types of data buffers".

Writing a good quiz question is actually kind of difficult ;)
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I've been following these posts, at least some of them, and what I'm missing is the why. Are you trying to develop a set of aptitude tests for hiring OE-specific resources? Are you trying to acquire OE platform knowledge yourself? Train existing staff? Something else?

When I read this, I'm inclined to to try understand the motivation for asking this in the first place. Is it because you read the phrase "data buffer" in the docs or a KB article, or heard them being discussed, and wondered what they are? If so, that context would be useful to have. As stated, this inquiry seems to me more like a trivia question than a search for understanding.

Anyone know what are called data buffers?
How many types of data buffers are used in progress?
What are they?

"Buffer" is a generic term. It is a data structure in memory. Because its purpose is to store data, the qualifier "data" in "data buffer" doesn't add meaning; to me it sounds like "beverage glass" ;). A buffer may be a cache, or an addressable unit of storage within a cache. Caches are used everywhere in computing, from CPU and network hardware to storage devices to OSes to software platforms to the applications built on top of them and the front-ends through which users interact with them. Buffers can be on the client-side, the application tier, DB server-side, or elsewhere. Progress uses the term "buffer" in many different contexts within OpenEdge. Even within a single component like the database or the AVM there are many different types of buffers.

I think it's more fruitful to try to understand concepts (e.g. what the various platform components are, what are the functional units within them, how they work, how they interact with each other, how to configure them, etc.) rather than memorize definitions or sets of high-level questions and answers. As you progress with OpenEdge, you will have lots of gray areas in your knowledge and perhaps also some misconceptions. That's true of all of us. We're all on a continuous journey of learning and no one is infallible or knows everything, not even the folks who build the platform. So I suggest that for a particular area of interest, start a discussion thread, state your assumptions and any relevant information about your situation (e.g. OE version, platform info, etc.) and then ask a set of specific questions. If you don't understand the answers or they seem to contradict things you already know (or think you know), state the perceived conflict and ask follow-up questions. If you are earnest and ask good questions and put at least as much work into your inquiries as you hope others will put into their responses, this site will be a beneficial resource for you and you'll be on the path to understanding.

If you wonder what I meant above by "good questions", maybe some examples will help.
Good questions:
  • When I run find first customer use-index cust-num. // (sorry Tom...) and the database engine gets the rowid of that record from the index, how does it know whether the latest copy of the record block that contains that record is in the database buffer pool or out on disk?
  • When I run run foo.p. for the second time in a client session, what does the AVM do? Does it search the propath again for the corresponding .r or does it run a cached copy of the program that it ran the first time? Is this behaviour configurable in any way?
Bad questions:
  • How does the propath work?
  • Why is my database slow?
  • Can you write me a program that does X?
A good question provides context. It helps others understand what you know already, what misconceptions you have, and the level of detail you're capable of absorbing in an answer. Most people here will bend over backwards to help you (for free!) if you approach them in a reasonable way and don't waste their time. But don't expect that if an inquiry comes across like "please write my exam/complete my assignments for me".

Also, with regard to the discussion in another thread from 2011 that seems to have started this, I fully agree with @tamhas. Ultimate success in hiring an OE resource (whether developer, technician, or DBA) isn't a matter of constructing a quiz and selecting the person who gets the high score. Most of the best OE developers and architects I've worked with over the years had zero OE knowledge before joining us. But they understood concepts like systems design, application design, API design, OOP, learned and practised in other languages and platforms. I believe it's much more important to have a good (and modern/evolving) understanding of these concepts than to have encyclopedic knowledge of the esoterics of OE.
 

TomBascom

Curmudgeon
I believe it's much more important to have a good (and modern/evolving) understanding of these concepts than to have encyclopedic knowledge of the esoterics of OE.

I couldn't agree more.

I will add that if you have an encyclopedic knowledge of the esoterics of OE that I will be deeply suspicious that your code reflects that and, as a result, it is an unmitigated fuster-cluck. (If you know that certain constructs have strange behavior which you have to reference the documentation to clarify and remind yourself why it is such a bad idea to use X that's ok.)
 
Hi Rob, You have articulated so very clearly how to get an understanding of any specific topic. Apologies for coming across bluntly with a series of Quiz questions - it has been a while ago since I used OpenEdge and so was trying to figure out where I stand and came across this quiz type questions posted and so picked it up from there! I am really sorry - my intention was definitely not to waste anyone's time, but purely to see if I still remembered the basic concepts.

You have given a fabulous explanation of buffer and the best way to get the queries across - sure I will keep that in mind and will come back with specific questions that helps in a better understanding of that specific concept.

Tom and Rob, I really cannot thank you enough! Appreciate your valuable time!
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
No need for apologies and it wasn't my intention to admonish you. I'm just trying to understand what you are trying to accomplish and help you to get help.
 

TomBascom

Curmudgeon
I am very pleased that you took me up on the idea to post _your_ answers and get feedback. IMHO that is one of the best ways to learn.

Being wrong about something is nothing to fear. I learn way more from being wrong, and working through understanding how and why I am wrong, than I do from keeping quiet and being too worried to post.
 
Another approach OpenEdge 11.7 Documentation
Data-handling statements
Statements that move data from one location to another are called data-handling statements.
ABL stores data in various locations—a database, a record buffer, a screen buffer, etc. A database stores application data on disk. A record buffer stores data temporarily while a procedure accesses the data, and stores the values of variables used in the procedure. A screen buffer stores data being displayed on the screen or being sent to another output destination; it also stores data that is being entered from the terminal or other input source.
 
Top