Month: April 2020
These challenging times of self isolation and home working will hugely disrupt the working practices of many of you, whilst for others who already work in an office at home, your working life might remain largely unaffected by the current crisis.
For people who usually work in an office with a server based database you have a few options available to manage how you can work remotely. The strategy you choose will be based on the availability of resources and the need to integrate with others.
The basics. To run StrataBugs you will need two things: a licence and a connection to a database. There are many different configurations for both these things, and they both can either be provided centrally on a network, or to distributed stand alone machines.
We usually provide permanent licences to a server or a hardware key (dongle). In the server model, as long as you’re connected to the server and the server has a licence available, then it can be “checked out” for the duration of your session and it automoatically returns to the pool when you close. We can also extend this model to provide a licence that can be checked out from the server for a continuous period of time, up to a set limited number of days. During this period, the licence can be used independently of the network. If you look at the Control Panel Config options, and the option for “Licence check in/out from server” is not greyed out, then your licence server has this enabled. This is useful for workers due to be working off line for example at rig site where a network connection to the server is not guaranteed, but could also be used for periods of home working.
Checked out licences reduce the number of remaining licences available to others, so its use should be carefully managed to avoid people being uncessarily locked out while a licence isn’t actually required.
For individual licence holders we usually issue a dongle. This is provided with a matched licence file and has the advantage that it can be moved from machine to machine, giving the same flexibility as a server licence without the need for a network. The disadvantage is the need to have a driver installed on each machine before the dongle will be recognised.
We can also licence individual machines based on their host ID(s) which are a unique aspect of the machine’s hardware. We do not issue permanant licences for individual machines because this would remove the flexibility to transfer between multiple machines or upgrade hardware.
For these exceptional times, if you would be normally able to connect to your company licence server but are unable temporarily to do so, then we can issue a temporary licence, if you provide us with the hostid. When sending us the hostid, please copy and paste the text rather than sending a screenshot to reduce the chances of retyping it incorrectly.
In StrataBugs you can set up one or more connections to databases. For most, you will only have one database that you connect to all of the time, but if that database is on a server, then when working remotely that server might be unreachable or simply too slow or intermittent to adequately work. One tip here: if you have the option, used a wired connection i.e. an ethernet cable, into your router, rather than a WiFi connection. We have found that database connections frequently get dropped when used over WiFi. Although we try to trap these instances and allow you to reconnect within StrataBugs, this isn’t always reliable.
If you find that you can’t work effectively using the remote server connection, then you can set up a connection to a local database. We use a file based database system called h2 which provides good performance for a single user. There is an h2 database called “demo” which you’ll find in the StrataBugs data folder. All the connection details for getting started with the h2 demo database are given on this page.
The demo database will obviously not contain any of the data you will have been working on in your server database. If you do need to carry on working where you left off, you have two options.
Firstly, before leaving the office, or if you can connect to the server remotely, you could run the Organiser module and run the guided export for all the data you’re working on. Use the default file format .sbg since this will best preserve the data for version 2.1 – older more obsolete formats like DEX have some deficiences for some data types. Save the export file to a folder location that you will be able to access offline.
When reconnected to the local database, you go through the Organiser guided import procedure, generally “adding all” as you go, and this will give you a new copy of the data into your local database that you can now work on.
There is a second option here. In the Wells and Outcrops module, there is a option for a Project (which is a list of wells and associated groups and templates) called “Create DB” which allows you to create a standalone database whch contains all of the project data. This avoids the import/merge steps of the above, but be warned, it places a heavy demand on the server and should only be run locally or over a fast enough network. It’s also sensitive to any errors in the data, so don’t be too optimistic that it will work first time! In this process, you start with an empty h2 database which just contains the table structure and some ancilliary data. See the help for a link to this database. At the end of the process you will have a file containing an h2 database which just contains your project data. One omission however is that it will not contain “Global” chart templates. See below.
If you use the export/import method, or you want to use global templates that the “Create database” step does not (yet) provide, you might want to also export some of your server’s global well blocks. You can do this from the “Chart/template” menu in the Charts & Templates module. If your well block uses groups and sets then these will be exported along with the panels that make up the well block. This also creates a .sbg file which you can import using the guided import of the Organiser module.
Don’t forget to backup your database file – nobody can replace this if it gets corrupted and you might lose all your data. On the connection settings there is a handy backup reminder prompt which pops up when you close the database.
Regardless of the method you use to get started, sooner or later you will want to get all that new or changed data back into your server database. The only option here is the reverse of the export/import method described above, except this time you’re exporting from the local database and importing back into the server database. If you have a lot of wells in your local database, remember to keep a note of which ones you’ve touched. The Oganiser guided import will allow you to see exactly what’s changed and give you the option to deal with any conflicts that arise during the merge.
As always, contact us if you need any help in managing your data.