Updating Calypso Save / Restore profile?

[[Ca...]]

Hello guys,

I’m wondering if somebody would have a good idea about how to backup your Calypso before upgrading to a newer version?

I just did an upgrade on an O-Inspect from 6.6 to 7.6 which is for sure a quite huge jump, but to lower it the same, I tested it on my offline station.
Calypso has the function to back up your profile “Extras > Miscellaneous > Maintenance > Save / Restore”, but it's not working very well for me.
For example, the Stylus Database is not completely backup: The Original Database is in “C:\Users\Public\Documents\Zeiss\CALYPSO\config\equip\Simulation” but here I have 2 databases, the “sdodata.mdf” and the “sdodata2.mdf”, here I don’t know to be honest when the second database happens, but this is my latest one (you can see it on the date), but when you use the normal “Save” from Calypso it only Backups the “Sdodata.mdf” not both, so all my stylus systems are not there. Additionally, I’m wondering why it's not possible to keep the Base / Start alignments. We are using lots of fixed zero points on Erowa fixtures and if I have to probe them manual, then it's quite painful to reprobe them all again.

For sure, I understand it's possible to simply copy all this manual and it looks like that works, but should it not be the case if you have a “save” profile option?

Was already thinking about writing a small program to backup all the manual folder, how are you doing this?

Regards,

[[No...]]

Backing up the stylus database correctly under all circumstances was a long-term issue during a number of Calypso versions. Unfortunately this was not openly communicated to the customers by Zeiss. I was relying on the backup function to save all important data and only discovered the missing database by pure chance (thankfully before anything bad had happened).

The underlying problem with this is that SQL Server changes the access permissions of the database file to admin-only once it acesses the database (that is, as soon as you connect to the machine tab, or perhaps even as soon as you start Calypso). Since this is managed by an external piece of software and a couple of services, Calypso itself often lacked the proper permissions and therefore had a hard time backing up the database. But it didn't bother to display any error message if it failed.

I've seen a number of efforts to solve this problem over the years, like an additional helper tool sent to me by the support, which was meant to detach the database from SQL Server's grasp. It worked, but in the next release the problem returned.
This issue was only resolved for good in one of the most recent releases. Calypso now exports the whole database content to binary files named something like <number gibberish>_data.bak during a backup and reimports the data during restore. This way it never needs to copy the database files itself.

You should copy over the old database files to the new Calypso folder once by hand. In the new version, the DB backup will work as intended, although you might still see missing *.mdf files. The *.bak files are the important ones now.

As to the base alignments, these were never backed up by the save function and are still left out to this day. Heaven knows why. But if you install the new version parallel to the old one and log in as Master you can migrate all your old data including base alignments. For regular backups I made a batch file that saves all the important files not covered by the Calypso function, like base alignments, Autorun desk, additional QDAS config files and so on.

[[Ca...]]

Thank you very much for your extended answer.

I compared the backup.set and which files are included, which I can link to which folders to perhaps write an own small tool to backup.
Here it looks that its not possible that way, because some files are not available like that 

Who did you that if im allowed to ask?

*basicReportTemplates
-C:\Users\Public\Documents\Zeiss\CALYPSO\protocol\BasicReportingTemplates\*.*
--Renamed folder

*cmmParameterFiles
---Physically not available (parameter.dat)

*config
-C:\Users\Public\Documents\Zeiss\CALYPSO\config\*.*

*customPrintout
-C:\Users\Public\Documents\Zeiss\CALYPSO\protocol\protform\*.*
--Renamed folder

*data
-C:\Users\Public\Documents\Zeiss\CALYPSO\data\*.*

*formplott
-C:\Users\Public\Documents\Zeiss\CALYPSO\protocol\formplott\*.*

*metadata.txt
---Physically not available

*nameAllocation
-C:\Users\Public\Documents\Zeiss\CALYPSO\data\config\*.*

*qdasConfiguration
-C:\Users\Public\Documents\Zeiss\CALYPSO\qdasconv.con

*toolboxes
---Physically not available (superFeature, opentbx)

*users
-C:\Users\Public\Documents\Zeiss\CALYPSO\config\env\*.*
---Physically not available (users\values)
C:\Users\Public\Documents\Zeiss\CALYPSO\scheme.dat
C:\Users\Public\Documents\Zeiss\CALYPSO\curveParameter.txt
---Physically not available (schemeCons.dat)
C:\Users\Public\Documents\Zeiss\CALYPSO\curveTmp.txt

------Additional------

*C:\Users\Public\Documents\Zeiss\CALYPSO\workarea\basesystems

[[No...]]

My batch file does not backup to the backup.set file, so the different folder structure in there is not my concern 😉
I'm only copying the files which are a) important to me and b) not saved by the Calypso function.

The following is my current batch file. It also creates a log file. It requires the target directory as a parameter.

echo off

REM  # Backup-Script wegen neuer Verzeichnisstruktur und interner Backup-Funkion in Calypso 2014
REM  # Von der Calypso-internen Funktion werden bisher NICHT gesichert:
REM  #
REM  # - Basissysteme unter \workarea\basesystems
REM  # - die zusätzliche QDAS Config-Datei "qdasconv_qsstat.con"
REM  # - Autorun-Oberfläche
REM  #
REM  # Das Script sollte VOR der Calypso-internen Backup-Funktion aufgerufen werden, weil es bei bereits vorhandenem
REM  # Sicherungsverzeichnis sicherheitshalber abbricht.
REM  #
REM  # Änderung 05.07.2016:
REM  # --------------------
REM  # * Kopieren von Einzeldateien mit xcopy /F, damit der Dateiname im Logfile erscheint
REM  # * Zusätzliche Sicherung der Autorun-Oberfläche "Autorun.arn"

cd /D "T:\KMG-Daten\CONTURA_SERIE\"
if exist %1 (
echo Verzeichnis ist bereits vorhanden!
echo ABBRUCH...
EXIT /B
)

REM  # Setzen des Verzeichnisnamens von Calypso als Variable, da dieser sich mit jeder Hauptrevision ändert
REM  # (z.B. CALYPSO 5.4, CALYPSO 5.8). So muss nicht jedesmal die ganze Batchdatei angepasst werden, sondern nur diese
REM  # Variable.

SET CALYPSO_DIR_NAME=CALYPSO

md %1\workarea\basesystems

xcopy "%PUBLIC%\documents\Zeiss\%CALYPSO_DIR_NAME%\qdasconv_qsstat.con" "%1\" /F >>%1\Sicherung.log
xcopy "%PUBLIC%\documents\Zeiss\%CALYPSO_DIR_NAME%\workarea\basesystems" "%1\workarea\basesystems\" /S /H /K >>%1\Sicherung.log

REM  # Sicherung Autorun-Oberfläche

xcopy "T:\Zeiss\Calypso\inspections\Autorun.arn" "%1\" /F >>%1\Sicherung.log

[[Je...]]

US users: Please review the ZEISS Portal Knowledge Base

https://portal.zeiss.com/knowledge-base ... &id=444235

[[MP...]]

I'm assisting in an update from Calypso 3.8 (yeah, ancient!) to 7.6. Is there a utility to migrate the DBs from that far back to the new system? What DB software or library was used back then? (Apparently, a Zeiss engineer installed 7.6 for us remotely and the new stylus DB was corrupt, resulting in Calypso throwing a DB connection error when it started. I reinstalled SQL Server and want to recreate the DB from the old data.)

A more robust solution wouldn't back up proprietary DB files but instead save the DB as a SQL script that could be run from the new DB's manager utility (in addition to being imported by the restore function). The script would be immune to permission problems imposed by an outside process.

I do the same thing when updating other software that uses a separate DB, such as our web and application servers.

Ken (MPA IT/Network admin, helping our CMM folk with an update)

[[No...]]

Please sign in to view this quote.

Older releases used an Access database (and maybe some additional proprietary stuff?), but I can only speak for versions as far back as 4.6
If the Zeiss support can't provide a better solution, I would first install the version that introduced SQL Server for the first time (I think it was 5.0), hoping that it contained the proper conversion routines. Then, if everything works well, upgrade to the current release.

Please sign in to view this quote.

Well, your signature says it all 😃 As far as I know the SQL Server management utility needs admin rights. But not everybbody is an admin on the CMM PC (me included), so Zeiss needed to implement a solution that doesn't require elevated permissions, and even more important, no database knowledge by the operator.

[[MP...]]

Thanks, I'll see if I can find out more about the Access-to-SQL path.

[[Ca...]]

Thank you Norbert for your small script 🙂
I will have a look and adapt it to my need 😃