Multiple Clients
On this page
6.5 Multiple Clients
6.5.1 Design and Operations Planning
Use a controlled CDPS publisher and locally installed COC stations. Centralize business records where appropriate, while deploying drivers and personal settings locally. Do not default to everyone running the same network EXE or editing one release source. Record program/layout versions, roles, devices, and owners; do not share administrator identities.
| Example node | Responsibility |
|---|---|
| DESIGN01 | Local CDPS, StaffCard design/group SQL/publishing, no automatic production. |
| DB01 | Server database staffcard, shared personnel/cards/status, native backups. |
| FILE01 | Controlled \\FILE01\CREVIAPhotos share only when folder photos are used. |
| COC01 | Local COC/printer A; designated automatic station if required. |
| COC02 | Local COC/printer B; separately assigned manual work or standby, not the same automatic scope. |
These are illustrative roles, not a requirement to buy five computers. Existing infrastructure may host services. Sharing a layout does not extend design-side database rights to operations accounts.
6.5.2 Shared Data and Resources
Pilot one station first and validate actual Windows/database accounts. Same-name local paths or mapped drives may target different resources. Network file databases require engine-specific concurrency/locking and reliable access; cloud synchronization/offline replication is not a shared-write database scheme. Prefer evaluated server solutions where reliability/concurrency requires them.
- On DESIGN01 configure DB01/staffcard, test, inspect fields/main SQL, complete the wizard, and save the entire layout.
- If using folder photos, access the same sample through the share under each real operator identity. Test approved replacement writes separately; read-only users need not receive deletion rights.
- On COC01 load the release, verify data/photos, select local printer A explicitly, use one copy, and test one fictitious card.
- Repeat on COC02 with its printer B rather than copied device choices.
- In isolated test data, edit/save on one station and refresh on the other, then restore the sample. Investigate targets, role scope, and refresh before production if results differ.
Diagnose host reachability, service/actual port, matching provider, identity/permissions, then main/group SQL. Do not open every inbound port.
Figure 6.5-1. Show an English fictitious topology with publisher, locally installed COC, shared data/photos, and local devices. Distinguish release traffic from business reads/writes; hide live addresses.
6.5.3 Publishing and Synchronization
For file delivery, save a verified release, distribute a copy to each project's local folder, open, log in, set default, close/reopen, and record the version. Copying files alone does not switch an already-open window. Distribution does not install drivers or migrate data.
For synchronization, configure/save .clcf, then publish the layout through CDPS Save. Design settings remain in CDPSDefault; COC stores the entry in CocDefaultTemplate and newer designs in Template. Open the configuration on each client and verify title, fields, a recognizable change, then role/data. Similar modification times are not proof. Keep automatic work off after failure and correct the source, not a long-term private edit of the download.
Synchronization concerns layouts, not all workstation settings or personnel replication. Set as Default on an ordinary .skdCard exits synchronization; distinguish this deliberate mode change from network failure.
6.5.4 Concurrent Edits and Duplicate Production
Group SQL, selection boxes, and session-only duplicate suppression are not distributed locks. Define ownership, claim/completion state, errors, and reprint approval. One designated workstation should own a batch unless the business/database system provides tested mutual exclusion.
Agree editing responsibilities and conflicts. After disconnects, save failures, or unclear output, inspect actual data and cards before resubmission. Verify artwork, chip, and state separately.
Without task claiming, manually assign disjoint batches. End the first task, count cards and status, and let the next station reread confirmed incomplete records. Isolate individual failures instead of resetting the whole batch to pending. The example uses one automatic workstation and does not claim that CREVIA supplies a cross-station lock.
6.5.5 Pilot, Rollout, and Handover
Validate environment, layout, scope, photos, and one saved record; test release/update on a second station; test allowed/forbidden actions with different roles; obtain small-sample print/write acceptance including retries; establish backups/notifications; then roll out in stages with signed workstation records.
Use an approved compatible version combination. Do not mix unverified old/new clients on the same automatic batch. Stop the affected scope and preserve evidence on failure.
Figure 6.5-2. Compare two demonstration clients with the same release and different role scopes, plus a deployment checklist. Distinguish program version, layout version, account rights, and device ownership.