Tom:
Yep. Totally wipes v001_ prefixed variables ... where desired.
My preference is to CLEAR VAR v00x_% only when I KNOW that I won't be
returning to that particular code segment within a session; saving the
engine from having to reload and re-reserve "space" for variables over
and over.
Alway best regards, Tom.
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 "Tom Hart" <[email protected]>
To [email protected]
Date 3/13/2025 11:26:17 AM
Subject Re: Re[2]: [RBASE-L] - RBase Project Update System
Can't you use clear var v001_%
Tom Hart
On Thu, Mar 13, 2025, 1:17 PM Bruce Chitiea <[email protected]>
wrote:
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
<https://www.google.com/maps/search/1142+S+Diamond+Bar+Blvd+%23+442+Diamond+Bar+CA+91765-2203?entry=gmail&source=g>
Diamond Bar CA 91765-2203
<https://www.google.com/maps/search/1142+S+Diamond+Bar+Blvd+%23+442+Diamond+Bar+CA+91765-2203?entry=gmail&source=g>
[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
<https://www.google.com/maps/search/1142+S+Diamond+Bar+Blvd+%23+442+%0D%0A+Diamond+Bar+CA+91765-2203?entry=gmail&source=g>
Bruce A. Chitiea
SafeSectors, Inc.
1142 S Diamond Bar Blvd # 442
<https://www.google.com/maps/search/1142+S+Diamond+Bar+Blvd+%23+442+%0D%0A+Diamond+Bar+CA+91765-2203?entry=gmail&source=g>
Diamond Bar CA 91765-2203
<https://www.google.com/maps/search/1142+S+Diamond+Bar+Blvd+%23+442+%0D%0A+Diamond+Bar+CA+91765-2203?entry=gmail&source=g>
[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
<https://groups.google.com/d/msgid/rbase-l/em0385798f-dcd6-4686-98be-2462e8a999b8%4077c4e4c8.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/CABX9BNcDfQGjvf-Ka9zL5eqa%3Dyn3kyC53QKVmALPCt5RuoTW8A%40mail.gmail.com
<https://groups.google.com/d/msgid/rbase-l/CABX9BNcDfQGjvf-Ka9zL5eqa%3Dyn3kyC53QKVmALPCt5RuoTW8A%40mail.gmail.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/em3d495429-6397-4669-bac5-440085490118%4077c4e4c8.com.
