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]<mailto:[email protected]>> To "[email protected]" <[email protected]<mailto:[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 --- 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]<mailto:[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 --- 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]<mailto:[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.
