Database Naming

When migrating a Synergetic Database to Single Database, the database name will be mandated based on an algorithm of:



  • {CountryCode} is the official two character code for the country of the school (AU, NZ, SG, EG or AE so far)
  • {RegionCode} is the two or three character abbreviation for state in Australia (WA, NT, SA, QLD, NSW, VIC, TAS, ACT)  or the three character abbreviation of island for NZ schools (NTH or STH)
  • {ClientIdentifier} is up to the first nine characters of the schools domain (looking at their website or email addresses).  This one we need to also eyeball to make sure we don’t end up with something offensive or not nice.  We also need to make sure that we don’t give a school the same DB name as another school so we may need to adjust if a school would end up with the same DB name as another (we haven’t had this problem yet as schools with similar domains have so far been in different regions).

We are not using the Synergetic code as the client identifier explicitly for three reasons:

    • They are inconsistent based on when the school came on board
    • They may contain region information which is now a duplication of the {CountryCode}{RegionCode}  portion of the name
    • The domain name is familiar to the users at the school.
  • {DBUsage} may be a Production/Live/Test database. PRD and TST are used for most clients

For example

      • Synergetic_AUVIC_CDA_PRD would be for a production environment 
      • Synergetic_AUVIC_CDA_TST1, Synergetic_AUVIC_CDA_TST2 would be two additional test databases
  • Note: The entire length of the name must be 30 characters or less (due to ODBCs and integrations with other systems

Victorian Catholic schools should be:



    • {Enumber} is the school’s E-Number

Existing Database Name Support

After performing a migration, your previous databases still exist and have been renamed with a prefixed of zPre68, for example zPre68SynergyOne, zPre68SynergyOneFinance, zPre68SynergyOneMedia, these databases are only intended for backup purposes and will not contain any new/updated data after the point of migration.

To continue to preserve existing functionality and third party integrations, synonyms have been created. However these do not store information and contain no Synergetic tables, views or stored procedures and only serves as a pointer/reference to the new database objects.