BUFFER name must not match table name
Mon, 2007-11-19 15:43 — rapier
| Project: | Prolint Issue Tracker |
| Component: | Rules |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
Prevent a BUFFER having the same name as a database table or temp-table.
e.g. (using Sports database).
Prevent DEFINE BUFFER Customer FOR Customer.
Prevent DEFINE BUFFER Invoice FOR Customer.
Allow DEFINE BUFFER bCustomer FOR Customer.
Allow DEFINE BUFFER banana FOR Customer.
I know that some people like to do this - but I've just spent an hour tracking down a mysterious 'record not on file' error that was caused by my typing in the wrong name for the buffer. This made it appear that my current record for my temp-table not available even though I had just read it (using a dynamic query in another function that i passed DEFAULT-BUFFER-HANDLE to)
- Login to post comments
Comments
Example
It has to be a bit more complex than that.
Example 1:
This occurred when importing data from csv files. I have a common piece of code that can imports CSV file into a temp-table. I just define temp-table to match the CSV.
The extra buffer was intended for some code I hadn't yet written - but I typoed the name.
Here are the important bits below - as simple as I can get them
DEFINE TEMP-TABLE ttCustomer NO-UNDO
FIELD abc AS CHARACTER.
FUNCTION FnFetchData RETURNS LOGICAL (INPUT P_H AS HANDLE):
P_H:BUFFER-CREATE().
/*
fetch data from somewhere and store it in the TEMP-TABLE
*/
RETURN TRUE.
END FUNCTION.
FUNCTION FnFetchCustomer RETURNS LOGICAL:
/*DEFINE BUFFER bttCustomer FOR ttCustomer. *//* this is what I meant to type */
DEFINE BUFFER ttCustomer FOR ttCustomer. /* this is what I did type */
FnFetchData((TEMP-TABLE ttCustomer:DEFAULT-BUFFER-HANDLE)).
MESSAGE AVAILABLE ttCustomer.
END FUNCTION.
FnFetchCustomer().
Example 2
DEF VAR vWibble AS CHARACTER NO-UNDO.
FUNCTION FnDisplay RETURNS LOGICAL:
DEF VAR vWibble AS CHARACTER NO-UNDO.
DEFINE BUFFER Customer FOR Customer.
FIND CURRENT Customer NO-LOCK.
MESSAGE Customer.NAME VIEW-AS ALERT-BOX.
END FUNCTION.
FUNCTION FnFetch RETURNS LOGICAL:
FIND FIRST Customer NO-LOCK.
FnDisplay().
END FUNCION.
FnFetch().
(This is just rubbish code to illustrate the problem.)
If you prolint this you will see 'variable vWibble in FUNCTION FnDisplay hides object in program scope'.
I would like to see the same sort of message for tables and temp-tables.
e.g.
'buffer Customer in FUNCTION FnDisplay hides object in program scope'.
Personally, having a buffer
Personally, having a buffer scoped to the procedure like this is dangerous, it would be a lot safer to pass a BUFFER parameter to your function and limit it's scope of possible interactions.
While I appreciate the
While I appreciate the difficulty this caused you, it looks to me as this problem was the result of your development habits. I know we all like to do what we've been doing forever, but if you used the "define buffer table-name for table-name" as your standard, you'd not only limit the scope of the default table buffers - and hence the possibility of untoward side effects, this kind of thing wouldn't even be an issue.
#1
Hi Derek,
I am not sure if I understand what the problem is. I can imagine a problem when the code goes like
DEFINE BUFFER banana FOR customer.
FIND FIRST babana NO-ERROR.
IF NOT AVAILABLE customer THEN ...
In this example, "customer" on the last line was the wrong buffer name. But enforcing your rule does not prevent that. Rule "bufdbproc" would, because it would say that "customer" is not a defined buffer.
But I suppose your code example was different. Can you give a small sample?