Robert: Hey thanks, happy to help. Additional thought, bear with me
here.
I'm a big fan of Variable Forms. But the fateful day arrived when
reliance upon the simple "vYourNameHere" format, applied across a series
of Forms and their embedded Form Actions, resulted in the Train Wreck
From Hell as arbitrary varNaming, CLEARing and NULLing practices blew up
the tracks. This has been solved with an object-name prefixing scheme
which regulates transport of values across Form boundaries; as well as
internally between a Form Action and its parent Form.
Here's an quick example using two variable Forms with Form-prefix
'addr_':
addr_hostForm_vfrm | variable prefix: v000_
addr_guestForm_vfrm | variable prefix: v001_
While running addr_hostForm_vfrm, the time comes to run
addr_guestForm_vfrm with the value held in variable v000_varName.
SET VAR v001_varName = .v000_varName
(note, the varName portion need not be identical; but see "train wreck",
above)
Within addr_guestForm_vfrm, the value of v001_varName gets washed and
rinsed, then sent back to addr_hostForm_vfrm:
SET VAR v000_varName = .v001_varName
Housekeeping on addr_guestForm_vfrm e.g. CLEAR VAR v001_%, is then easy
and error-free.
As regards Form Action variables, activity within addr_hostForm_vfrm is
similarly segmented:
-- v001_ | prefix for form-general variables
-- v0011_ | for Form Action #1 variables
-- v001a_ | for Form Action #a variables
... keeping everybody in his lane, and with the same housekeeping
advantages. (I look forward to the day when R:BASE can null out an
entire range of variables by their prefix with one command. )
And, of course, you can craft "universal" variable classes blanketing
both common and satellite environments using the RBG11 STATICVAR
feature; and, alternately, naming variables with a non-v prefix which
you'd have to really work hard to accidentally CLEAR or NULL, e.g. 'zv_'
The same atomizing format construction can be applied to any object
within the R:BASE environment.
Which implies that a big chunk of update management can be handled with
RUN SELECT out of one, or a handful, of simple tables.
Happy to talk anytime.
Bruce A. Chitiea
SafeSectors, Inc.
1142 S Diamond Bar Blvd # 442
Diamond Bar CA 91765-2203
[email protected]
(909) 238-9012 m
------ Original Message ------
From "rdiaz kcnyenterprises.com" <[email protected]>
To "[email protected]" <[email protected]>;
"[email protected]" <[email protected]>
Date 3/13/2025 6:03:54 AM
Subject Re: [RBASE-L] - RBase Project Update System
Good morning
I have not fully designed it yet, but the CORE elements are critical to
address. Great points and idea! I will definitely incorporate it at
the CORE levels! This will allow me to have much better updating at
CORE elements down to the column levels (and for the right companies)
and not just Forms, Reports, etc. Thank you!!!
--------------------------------------------------------------------------------
From: [email protected] <[email protected]> on behalf of
Bruce Chitiea <[email protected]>
Sent: Wednesday, March 12, 2025 1:12 PM
To: [email protected] <[email protected]>;
[email protected] <[email protected]>
Subject: Re: [RBASE-L] - RBase Project Update System
Robert:
I have not. So, out on a limb here. Would I be wrong to presume that
certain CORE elements interact differently with individual SATELLITE
elements, depending on each satellite's unique requirements? Have you
fully abstracted and mapped the linkage of CORE objects (columnName,
varName etc. ); and such SATELLITE objects which receive update values;
such that the right update never arrives at the wrong company?
Example of top-of-the-head trainee thinking, where all satellites
receive common updates, and each either receives a different value set,
or interprets that value set differently:
Update Sent ---------------
vcore_0_thing > portal (where the magic happens)
vcore_1_thing > portal
vcore_2_thing > portal
...
vcore_n_thing > portal
Update Received -----------
portal > sat1_vcore_0_thing
portal > sat1_vcore_1_thing
portal > sat2_vcore_0_thing
portal > sat2_vcore_2_thing
...
portal > satn_vcore_0_thing
portal > satn_vcore_1_thing | cannot happen!
You're pushing a boundary, there; exciting.
Very Best, Bruce
Bruce A. Chitiea
SafeSectors, Inc.
1142 S Diamond Bar Blvd # 442
Diamond Bar CA 91765-2203
[email protected]
(909) 238-9012 m
------ Original Message ------
From "rdiaz kcnyenterprises.com" <[email protected]>
To "[email protected]" <[email protected]>
Date 3/11/2025 1:39:39 PM
Subject [RBASE-L] - RBase Project Update System
Hello everyone,
I was wondering if anyone has written some sort of UPDATE system for
their Rbase projects.
We have several databases in use, live. One for each of our companies
we own. They all share some common code, stored procedures, forms,
reports, etc. And they have some unique programming, forms, reports
as well. For the common code, we always have to update them
individually. Its very time consuming and leaves lots of room for
error, even when careful and using checklists.
After speaking with John (Rbase) and Frankie (Developer of our ERP
system and Co-Owner of our company), got me thinking to develop the
following:
-----
Have ONE Database of which we have all the common code, reports,
forms, stored procedures. That ONE Database is only for DEVELOPMENT
and TESTING purposes. I will have a UPDATE SYSTEM Table in which I
will certain internal system data including when an update and its
version is ready to distribute, and for which companies.
We currently have a SCHEDULER system which has Schedule Tasks to do
many Database Maintenace, imports, health checks, Database Reloads,
etc. We will add a Daily CHECK FOR UPDATES Task to run nightly. This
will lock the Database during the update process. Then, LOAD any new
RMDs, Stored Procedures, Forms, Reports, Views and Labels, which are
designated to update AND to the proper Database. Finally, to Unlock
the Database for production use.
I will have a Message sent via Email (SMS, WhatsApp) out to the Users,
Alerting them of when the update will happen and that their access
will not be available during those times.
I will have a Message sent via Email (SMS, WhatsApp) out to the Users,
as a New Version Update and its new features, and that the update was
completed successfully.
-----
My question to everyone is, has anyone done anything like this? Any
other ideas, features, likes, dislikes? This group is EXCELLENT and
would love to learn and improve with any suggestions, DONTs and DOs,
etc.
Thank you,
Robert Diaz
--
For group guidelines, visit
http://www.rbase.com/support/usersgroup_guidelines.php
<http://www.rbase.com/support/usersgroup_guidelines.php>
---
You received this message because you are subscribed to the Google
Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/rbase-l/SA1PR19MB51829C1711453E72CD616052A8D12%40SA1PR19MB5182.namprd19.prod.outlook.com
<https://groups.google.com/d/msgid/rbase-l/SA1PR19MB51829C1711453E72CD616052A8D12%40SA1PR19MB5182.namprd19.prod.outlook.com?utm_medium=email&utm_source=footer>.
--
For group guidelines, visit
http://www.rbase.com/support/usersgroup_guidelines.php
<http://www.rbase.com/support/usersgroup_guidelines.php>
---
You received this message because you are subscribed to the Google
Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/rbase-l/em6061157b-4c43-45ec-92ff-4bce29b401ff%40e85a645b.com
<https://groups.google.com/d/msgid/rbase-l/em6061157b-4c43-45ec-92ff-4bce29b401ff%40e85a645b.com?utm_medium=email&utm_source=footer>.
--
For group guidelines, visit
http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google
Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/rbase-l/SA1PR19MB5182E1F48DCE42A7F8EA9E0CA8D32%40SA1PR19MB5182.namprd19.prod.outlook.com
<https://groups.google.com/d/msgid/rbase-l/SA1PR19MB5182E1F48DCE42A7F8EA9E0CA8D32%40SA1PR19MB5182.namprd19.prod.outlook.com?utm_medium=email&utm_source=footer>.
--
For group guidelines, visit
http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/rbase-l/em0385798f-dcd6-4686-98be-2462e8a999b8%4077c4e4c8.com.
