Blue Jeans Breakfast 2019

On 6 June we co-hosted the Blue Jeans Breakfast with Global Z-Data and BizSmart, and we are overjoyed at the success that it was.

Our full house of guests enjoyed a morning of networking and breakfast, with an engaging discussion on Digital Transformation by our keynote speaker.  Ryan Hogarth was truly captivating and left us feeling inspired to re-look the way that we are doing business and how we are approaching the ever-changing world of technology.

Our sponsors for this event comprised Sage, Mimecast, ESET, Maxtec, Fortinet and CLOUD29.


Blue Jeans Breakfasts aim to bring together networking, education, collaboration and creativity in a relaxed environment.


We look forward to taking these conversations on innovation, business and technology further.  If you wish to make suggestions or collaborate on a future event, please do get in touch.


Database Mirrors: Ransomware Protection

Ransomware – the stuff of nightmares

Viruses, Malware, Phishing and even the dreaded Y2K of yesteryear – none of these “horror stories” keep IT Administrators up at night quite like the term Ransomware does. Like an “invasion of the body snatchers” type scenario, suddenly your data is no longer your own. It’s still on your server, on your very own infrastructure – but your data (arguably, the heart and soul of your operation) is no longer accessible. Even if you pay the Ransom, there’s no guarantee that the nightmare ends.

Yes, you can secure your “always online, always accessible” Server Environment, but the reality is that there’s always a possibility (however minute) of Ransomware lurking just around the corner. For some of us, we want – nay, need – just that little bit of extra confidence that we’ve sufficiently protected ourselves against Ransomware. Almost as if we’re looking for a sort of “chamomile tea” solution, if you would entertain the phrase; just that final bit so that we can rest easily with the assurance that we’ve done all we possibly can to prevent the threat.

As luck would have it, for one particular project, I was able to work hand in hand with an adept team to implement the very same sort of “chamomile tea” solution for one such concerned client.

Adding another layer of protection – a reflective layer at that

So here’s the scenario in a nutshell: The client commissioned another service provider (Skynamo) to implement a Mobile Sales Application that accesses data from a database that we (MRBM) look after. The IT Administrator has kitted out the SQL Server (named VEGA) with all sorts of Ransomware protections – Firewall, Anti-Virus, Secure Access policies, etc – the whole nine yards. However, he’s still apprehensive about opening up ports on VEGA, essentially having it open to the whole WWW. That’s when he pitches his “chamomile tea” solution – they’ve got another server (SIRIUS) which was previously used as a test environment for Custom Development that hasn’t been in active use for some time. He’s happy to open up ports on SIRIUS (being a non-critical Server), so he asks if we can mirror the database from VEGA to SIRIUS so that the data can be accessed from there instead.


As with most IT solutions, the answer was “of course we can – but it’s not necessarily straightforward and not without some caveats”. There were several challenges to overcome:


VEGA and SIRIUS were running SQL Express 2014 and SQL Standard 2008 R2 respectively.

  • While SQL Express does support some mirroring, it can’t act as a Primary Mirror.
  • Other issues arose from this as well – inability to restore to lower version, etc.

The Mobile Sales Application only needed to access Master Data (less than 1GB worth)

  • While the entire database was not large (< 20GB) it would have been redundant to mirror it entirely (transactions and all) for only a sliver of data to ever be accessed.

Lastly, and the most challenging, VEGA and SIRIUS had differing default SQL COLLATIONS.

  • Any database admin worth his salt knows that mixing COLLATIONs is bad news.
  • Because of how we had to implement this (without traditional mirroring), this had its own separate cadre of challenges to overcome.

Now as service providers on opposite ends of the problem (making the data available vs consuming the data), it’s a good thing that we had a solid working relationship from having collaborated on a couple projects across several sites previously. Had that not been the case, we most likely wouldn’t have been able to fully realize the solution that the client wanted. In the end, here’s how we did it:

We implemented the entire Mirror using SQL scripts.

  • And we do mean the entire Mirror. Oh, we tried several things first – Copy, Restore, Base Copies of the Database and few other things. Most of these fell flat because of issues with the Version and COLLATION differences.
  • This included Tables, Views, Functions, Triggers and all the in between plumbing that made the database work, with specific focus on getting the objects in place for the Mobile Sales Application.
  • Both Service Providers worked closely, pruning and perfecting scripts until the scripted Mirror worked as intended.

Summary – Reflecting on the solution

It’s a very non-traditional solution, but it works. We’ve got a Database Mirror without implementing SQL Mirroring, a fully Scripted Database Synch with JOINS and FUNCTION CALLS across Servers with differing Builds, Versions, Editions and COLLATIONs!

Trawling the web in preparing this “chamomile tea” revealed that many others had given up when presented with some of the challenges we overcame during this implementation. So why did we work that hard at achieving this for the client? Because, both service providers were on board with the idea that for the client, peace of mind is priceless.

If the unthinkable does indeed happen and Ransomware does hit SIRIUS, the IT Administrator can rest easily knowing that the soothing “chamomile tea” solution successfully protected VEGA from the brunt of the attack’s payload.

Are you ready for year-end?

Getting ready for Year End can be a daunting task, so we have compiled some checklists to help guide you through your Sage Pastel Partner Year End process.

Should you require an MRBM Consultation before Year End, please get in touch as soon as possible to make a booking.


To ensure that your Year End operation is successful, you are required to first perform the following checks:

✓ 13th Period Setup: 
A financial year consist of 12 periods. Sage Pastel Accounting allows for 13 periods in a financial year. The 13th period is used to extend your financial year with one period to complete the preparation for Year End.


✓ Inventory Stock Take: 
If you use inventory, it is important to do a stock take before proceeding with the Year End.


✓ Foreign Currency Revaluation: 
The Foreign Currency Revaluation needs to be run before processing the Year – End you will not be able to run the revaluation after the Year End.


✓ Open Batch: 
Prior to processing your Year End, you will need to update all open batches. This includes Sage Pastel POS Cash on Delivery (COD) and Sage Pastel POS On Hold documents.


✓ Retained Income Account: 
The Retained Income account is a Balance Sheet account that needs to exist in Sage Pastel Partner/ Xpress for the Year – End to be processed


✓ Bank Reconciliation: 
Prior to processing your Year End, you will need to make sure that all bank transactions for this year have been reconciled.


✓ Data Integrity: 
The Data Integrity is run before the Year End to ensure there is no data corruption.



The following Year End process should be conducted on the server. This is to avoid the system crashing if attempting to work on multiple companies at the same time from different workstations.

Note: Make sure that all your batches are updated. When you view the open batches, ticks should only be under quotes sales orders and purchase orders.  You cannot clear history with any open batches.

 Backup the Company.

Do this manually to a safe place before you start.

 Create a New Company.  

Navigate to File New, copy another company, put your cursor on the current company and then tick on the New tab. Make sure that you are creating the New Company in the same drive as the Current Company, in the new company name space put the new company name.  If you are currently using LEOG2018, you will create LEOG2019 for the new company of if you are using a fix name like LEOG create last year as LEOG2018, click CREATE.

When you copy, if Pastel displays the explorer instead of the navigator, then tick on the icon four from the very right at the top, and choose navigator rather than explorer. Please note that in some cases, where the dataset is very large, you may get an error 6, overflow.This overflow just means there is too much.If that happens, copy the whole directory, through the windows explorer, and then rename the copy.

 Using 13 Periods.

If 13 periods is selected, make sure “use last period as first period” is ticked. If 12 periods is selected, make sure this is unticked.

 Run a Data Integrity.

If errors pop up, the data should be data-fixed before continuing any further.

 Run the Year End Wizard.

If there are no data errors, run the Year End Wizard and follow the steps. Choose the option to not create new company as you have done this above.

 Backup Again.

After Year End, close pastel and reopen then perform another backup.

 In the New Company:
  • Go to change delete history/clear files
  • Clear history
  • Open item history for 3 years ago
  • Delete invoice history
  • Delete serial number history (if you are using serial numbers)
  • Clear open item history – customers and suppliers
  • Delete 3+ years transactions (only available from version 12+)
  • And project tracker if you are using that
  • All Gl Accounts from 0001 to 9999
  • All suppliers Blank to ZZZZZZZZZ
  • All customers Blank to ZZZZZZZZZ
  • Confirm what you are going to do

 Backup and Rebuild.
We recommend that you conduct another backup and rebuild acchistl.dat, acchisth.dat, accoi.dat, acctrn.dat.  This will take some time to complete if you have not done it for a long time.

 Check Periods, Data Integrity.
Once the above is complete, go into setup periods and make sure the new periods are correct.  Conduct another data integrity.  We usually also take away the 13thperiod so that users do not accidentally process into period 13.

 Entering the New Year.
Make certain that you process into PERIOD ONE of the new year.

 Backup, Again.Take a backup of this before you start.

Load Shedding: Protect your data

Load Shedding is unfortunately back again and we have subsequently noticed an increase in data corruptions.

One of the reasons for this is that our computers and operating systems are not designed to support abrupt loss of power, but rather to follow their built-in processes of preparing for shutdown.  Instant loss of power can result in lost or corrupted data for certain file systems.

To ensure that your business data is well protected, we request that customers please review the Load Shedding Schedule on the Eskom website and make provisions to either shut down your equipment before the power goes off or make use of a UPS or generator to backup your power supply.

If you would like more information on how to protect your business against load shedding, please get in touch and we will explain how best to set up your equipment as well as the benefits of moving your business to the cloud.