SAV Inspector Deutsch
HomeVersion SPSS SAV files around the states people actually review.
Research team workflow

Version SPSS SAV files around the states people actually review.

Git is excellent for text but binary SAV files do not produce a useful line-by-line diff. Research teams usually need a different guarantee: which complete file state was created, why it changed, who reviewed it and which version is approved.

A version is a complete immutable state

Each deliberate save creates a new encrypted file version instead of overwriting the previous bytes. The timeline records creator, time, version number and comment. Older states remain available according to the organisation's retention policy.

  • Never reuse a version number
  • Keep comments short and decision-oriented
  • Review a specific version, not a mutable filename
  • Record the source and intended next step
  • Use hashes when an external handover must reference exact bytes

Comments explain intent; checks establish evidence

“Fixed labels” is weaker than “Added questionnaire-confirmed labels for q12–q18; case values unchanged.” A good comment explains scope and evidence. The SAV Check and round-trip report complement the comment with machine-verifiable findings.

Handle concurrent work explicitly

If two people open the same base version, they can create competing outputs. The safe near-term workflow is to notice that a newer version exists, review both intents and create a reconciled successor. Hidden last-write-wins behaviour is inappropriate for controlled research files.

Practical workflow
  1. Open a known base

    Start from a visible version number rather than an ambiguously named attachment.

  2. Make and check changes

    Keep changes explainable and run quality and round-trip checks.

  3. Save with a decision comment

    Describe what changed, why and whether case values were affected.

  4. Request review

    Have another authorised member approve or reject that exact version.

FAQ

Frequently asked questions

Why not store SAV files directly in Git?

You can store them, but normal text diffs cannot explain binary dictionary and case changes. A file-oriented timeline and domain checks are more useful for most research users.

Can an approved version be changed?

No. A change produces a new version that requires its own review.

What belongs in a version comment?

Scope, reason, evidence and whether values or only metadata changed. Never paste sensitive case data into the comment.

Does versioning replace backups?

No. Version history protects logical states; backups protect the service against storage or database loss.

SAV Workflow Check

Find out in 30 minutes whether SAV Inspector fits your workflow.

We take one concrete recurring SAV job, define the desired outcome and demonstrate the shortest Local or Teams path. No generic product presentation, no newsletter and no file upload by email.

  • one concrete workflow instead of a feature tour
  • no-upload Local demo or controlled Teams pilot
  • a shared success criterion
  • a clear recommendation — including when SAV Inspector is not a fit

Only used to reply personally to this request. No newsletter. No SAV file or file metadata is transferred through this form. Privacy Email us directly
Guides

Related guides

A controlled workspace for shared SPSS SAV files.Manage encrypted SPSS SAV files in projects with roles, immutable versions, comments and reviews. A controlled workspace for research teams.Give occasional SAV users a workflow that fits their job.A lean SAV workflow for market research project managers, data processing and quality teams: inspect locally, version securely and keep SPSS for experts.Check a SAV file before it becomes someone else's problem.Check SAV metadata, missing labels, identifiers, constants and writer compatibility before handover. Produce a reviewable quality report.