I store code in the database on a current project. The table was
designed for 7.1 so that I could store the eeps in the table and create
them as the form opened. Eeps on row change were available only as
external files in 7.1. Here is the table structure:
Table: FormEeps No Lock(s)
Descr: External Eeps are in this table, unloaded as needed
No. Column Name Attributes
--- ------------------ --------------------------
1 EepName Type : TEXT 24 NOT
NULL
Consrnt: PRIMARY
KEY
2 FormName Type : TEXT
18
3 EepCode Type : LONG
VARCHAR
Current number of rows: 6
I created a stored procedure that would unload the eeps for the given
form in a "before start" form action. I created the procedure so that it
could unload both on entry and on exit row level eeps with a single call
in the "on before start" form action. Personally, I think this would be
overkill for what you want, but it might point you in a useful direction.
-- In the on before start:
CALL FormEeps(.RBTI_FORM_FORMNAME)
RETURN
-----------------------------------------------------------------------------
-- FormEeps.prc
-- Albert Berry 03/2007
-- Creates external eep files on entry into a form
-----------------------------------------------------------------------------
SET VAR vFormName TEXT
SET VAR vEepName TEXT
SET VAR vEepCode VARCHAR
SET ERROR MESSAGES 705 OFF
DROP CURSOR c1
SET ERROR MESSAGES 705 ON
DECLARE c1 CURSOR FOR SELECT EepName, EepCode FROM FormEeps +
WHERE FormName = .vFormName
OPEN c1
FETCH c1 INTO vEepName, vEepCode
WHILE SQLCODE <> 100 THEN
OUTPUT &vEepName
WRITE .vEepCode
OUTPUT SCREEN
FETCH c1 INTO vEepName, vEepCode
ENDWHILE
DROP CURSOR c1
RETURN
Wills, Steve wrote:
I think I've seen something somewhere related to this, but I wanted to
ask about it.
I would like to begin saving "work-in-process" statements to my
database. Essentially, these are DEV/TEST/"one-off" statements executed
from the R>. Historically, I've just saved them by copying-n-pasting
from the R> to RBedit files, named along the lines of
"SQL_2DAY_CCYYMMDD.TXT". However, even with comments, I am now finding
this approach FAR less than optimal.
So, my thinking to this point is that I'll need one table to hold the
statements and comments and a related "many-side" table to hold keywords
for searches.
Maybe :
SQL_2DAY
StatementPK INT (AUTONUM)
StatementString TEXT? (??)
StatementComments NOTE?
StatementCreateDate DATE
StatementCreateTime TIME
SQL_2DAY_KEYWORDS
StatementPK INT (FK)
Keyword TEXT (??) (PK: StatmentPK & Keyword)
So, would anyone have advice regarding this, especially with regard to
my basic design and/or your experiences having done something similar?
Thanks,
Steve in Memphis
J. Stephen Wills
Program Manager, Research Informatics
Office of the Vice Chancellor for Research
University of Tennessee Health Science Center
62 S. Dunlap, Suite 400
Memphis, TN 38163
Office: 901-448-2389
FAX : 901-448-7133
