Re: Built Server—Best Practices...
Problem solved! I'd built the server with the latest R3 version while the test server was running Hotfix 4. I re-built the server with HF4 and all is right with the world. Robert > On Dec 6, 2018, at 7:33 PM, Robert ListMail via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > Error: “The database or component “StructureName/4DC” requires the method > named “SVG_Clear” in the component “4D SVG” to be thread-safe.” > > Have you seen that before? ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Built Server—Best Practices...
I know I’ve swapped .4DC files for minor structure updates in the past on built-servers; yet, I just swapped out the entire “Server Database” folder in the built client and I’m now setting an error that I’ve never seen before. I’m sure I could copy over the massive server build and be done with this error but I was hoping to better understand why this error came up. Error: “The database or component “StructureName/4DC” requires the method named “SVG_Clear” in the component “4D SVG” to be thread-safe.” Have you seen that before? Thanks, Robert === Robert Broussard Houston, TX === > On Oct 16, 2018, at 2:24 PM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > but will say I've > been doing those sorts of updates to my built server app for - years. I've > never has an issue that tracked back to it. Yet. ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Built Server—Best Practices...
Robert, don’t know it this is relevant to your situation but many years ago, to get around the problem of losing the backup settings when installing a new built application version, I setup a system where, on quit, I stored the backups xml file in the data folder (or a record in the data - too long ago to remember exactly). Anyway, on startup it replaces the existing file with the stored file and away you go. It worked really well - no problems. HTH, Keith ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Built Server—Best Practices...
I only rebuild the entire client and server if there has been a 4D version change ie moving from 16.3 to 16.4 etc. Otherwise I build the server and just copy across the new .DC file from the Server Database folder. You need to make sure compiling on same version as deploying. Never had a problem and you dont lose the settings. -- Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Built Server—Best Practices...
to restore local backup settings (because the backup settings file is always located inside the application's preferences folder) I wrote this https://github.com/miyako/4d-utility-backup-dialog to get/set all settings as a single object (object notation required). I have a similar solution for building too (not published yet) for one thing, the standard GUI does not expose all possible keys. http://doc.4d.com/4Dv17R2/4D/17-R2.1720/4D-XML-Keys-BuildApplication.100-3929018.en.html also you might want better error handling. also you might want to run a sequence of builds using different settings. ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Built Server—Best Practices...
Thanked Kirk, Tim & Tim! :) This is what I thought you guys might say…. So, do you use the XML to do the build or the standard GUI? R > On Oct 16, 2018, at 2:39 PM, Tim Nevels via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > The “Best Practice” is to do what 4D TS says ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Built Server—Best Practices...
On Oct 16, 2018, at 2:00 PM, Robert wrote: > I recently started to use built client/server more often since I inherited a > client that was already doing that. I was told by another developer that when > doing a structure change that I can simply swap the .4DC file and I’m done. > 4D TS suggests that this is not wise and that I should probably use rsync or > simply supply the whole built client each time. So, what do you do? Hi Robert, The “Best Practice” is to do what 4D TS says — update the complete package and don’t fool with individual files. But I — and many others — live dangerously because we think we know what we are doing, are willing to suffer the consequences when we screw up and want to do a faster manual update of an application. If you know that all you have done since the last deploy is edit the .4DB in the Design environment adding and editing forms, methods and things in the Tool Box (excluding Resources) and the structure, then the only thing that will change when you do a build is the .4DC and .4DIndy. I have one client that I do this for constantly. Done it probably over 50 times over the years. Never a problem that I didn’t create by not following the above rule. I have another client that I NEVER do this for. I’ve got a very easy to use auto update system in place and it is actually easier and faster to just replace the complete application package with each update. (If I ever find the time and get motivated, I’ll create a system to do this for the first client.) > Also, when building the built client/server do you use the 4D commands with > the XML project or do you use the GUI? > > I was happily using the GUI and editing the engined server link file in the > client such that it points to the correctly deployed server as it defaults to > the local development server….. However, I found another issue, the backup > settings and maybe the cache settings were not set on the deployed server > deliverable and I set these manually. How do you manage these settings? I use a hybrid system. I first use the Build dialog to set everything that I can and then do a test build to prove that it works. Then I have a “Build Application” method that takes the BuildApp.xml file from the dialog and adds all the custom build keys that I need to do a deployment build. For backup settings, you have to find a way to copy the current “Backup.xml” file from the installed version to the new version. One way is to script that during the installation of the new version. Might be a way to automate creating this file during a build, but you would have to communicate with the running 4D Server somehow and extract the needed information and then manually build Backup.xml so that it was identical to the one on the server. Put that in the right location in the new version. Backup settings and the “Log” folder is one of the reasons why for the one client I just install the .4DC and .4Dindy. Then I don’t have to worry about copying these things from the old version to the new version. For cache settings just turn on the Database Settings -> User Settings on the machine and it takes care of itself. Tim * Tim Nevels Innovative Solutions 785-749-3444 timnev...@mac.com * ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Built Server—Best Practices...
Robert, I wouldn't presume to argue with Tim on best practices but will say I've been doing those sorts of updates to my built server app for - years. I've never has an issue that tracked back to it. Yet. The main benefit is users don't have to wait through downloading a new set of Resources/Components and Plugins after each update. Over HTTP this can be a long slog. The downside, which is why 4D recommends against it I suspect, if that it's totally on you be sure there isn't some little thing in Resources/Components/Plugins that may have changed and causes problems. If the app builds successfully you know that everything in the database folder is OK to work together. However, with that said there may be a lot of little things in place on a production server that have no relevance anywhere else. Or you can't really duplicate. SSL certs, web folders, other kinds of configuration files. Updating a server is not a small thing. On Tue, Oct 16, 2018 at 10:44 AM Robert ListMail via 4D_Tech < 4d_tech@lists.4d.com> wrote: > I recently started to use built client/server more often since I inherited > a client that was already doing that. I was told by another developer that > when doing a structure change that I can simply swap the .4DC file and I’m > done. 4D TS suggests that this is not wise and that I should probably use > rsync or simply supply the whole built client each time. So, what do you do? > > Also, when building the built client/server do you use the 4D commands > with the XML project or do you use the GUI? > > I was happily using the GUI and editing the engined server link file in > the client such that it points to the correctly deployed server as it > defaults to the local development server….. However, I found another > issue, the backup settings and maybe the cache settings were not set on the > deployed server deliverable and I set these manually. How do you manage > these settings? > > Thanks, > > Robert > ** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ** -- Kirk Brooks San Francisco, CA === *We go vote - they go home* ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
RE: Built Server—Best Practices...
Just to clarify - The suggestion from 4D Technical Support is to include 100% of the entire application package that is built by 4D. Typically this is done by archiving the application in a ZIP file or on a DMG and transferring the archive to the destination machine where it is unarchived. You can go a step further an use an installer also. In a situation where there is limited bandwidth (if you feel that transferring the whole package is too much), then as an alternative you can try to use a product like RSYNC or ROBOCOPY. Using these 3rd party tools you can skip the files that are identical between the source and destination, and only transfer the files that are different. Typically doing a transfer in this way would include more than just the 4DC. The overall goal of both approaches is to get the application to the destination machine in a way that makes it so that the files running on the destination machine match the files that were built. -Tim > However, I found another issue, the backup settings and maybe the cache > settings were not set on the deployed server deliverable and I set these > manually. How do you manage these settings? Using "User Settings" allows you to manage the cache settings in an external file at the deployment site: http://doc.4d.com/4Dv15/4D/15.6/Using-user-settings.300-3836796.en.html However the backup settings are not included in user settings... So you can manage the backup xml file as outline in the following tech tip: Tech Tip: Retaining the Backup Settings when upgrading a merged application http://kb.4d.com/assetid=77988 -Tim ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Built Server—Best Practices...
I recently started to use built client/server more often since I inherited a client that was already doing that. I was told by another developer that when doing a structure change that I can simply swap the .4DC file and I’m done. 4D TS suggests that this is not wise and that I should probably use rsync or simply supply the whole built client each time. So, what do you do? Also, when building the built client/server do you use the 4D commands with the XML project or do you use the GUI? I was happily using the GUI and editing the engined server link file in the client such that it points to the correctly deployed server as it defaults to the local development server….. However, I found another issue, the backup settings and maybe the cache settings were not set on the deployed server deliverable and I set these manually. How do you manage these settings? Thanks, Robert ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
