REQUEST A DEMO

Tag: diet

GDPR and the Right to be Forgotten

July 24, 2018 Recently I've been having more and more conversations around GDPR, and specifically the Right to be Forgotten portion of the regulation. So if we have a customer that asks to be forgotten, how do we deal with that? And what does that mean within our Clarify/Dovetail systems? Often, the conversations dive into what data do we need to get rid of. Customer Information In our CRM / case management systems, the customer record is pretty contained. We have the contact table for the person itself, which has the person's name, phone number, email address, etc. And we have the e_addr table, for their additional phone numbers, email addresses, and web sites. There's some slight differences if we're dealing with B2C or B2B organizations. With B2C, where we might be dealing with Individual Contacts, we may also need to deal with the related…

DIET: DELETE + INSERT instead of UPDATE

June 30, 2015 When we have to insert, update, or delete data, DIET (Dovetail ArchiveManager) is often the tool of choice. Updating an object Typically, when we want to update some data, we just need to define its uniqueness properly. For example, if I wanted to update a business rule property name,  I could define its uniqueness as a combination of its object type + name. For example: OBJECT TYPE="prop_name", NAME="commitment case id" UNIQUE_FIELD=obj_type, prop_name FIELDS obj_type=30; /* object type 30 = commit_log */ prop_name="Case ID"; path_name="case_commit2case:id_number"; subtype=0; val_type=0; max_len=255; END_FIELDS END_OBJECT NAME="commitment case id" If I used DIET to import this file, and this prop_name  record didn’t exist in the database, then it would do an INSERT, which would create this prop_name record. If I used DIET to import this file, and this prop_name record did exist in the database, then it…

Automated Deployment for Clarify Example

January 11, 2012 Last year I posted about automated deployments for Clarify. From that post:   Doing automatic deployments of Clarify changes is pretty straightforward. If I was starting off, I would use a contemporary build script tool such as nant or rake, and simply have it call out to your schema editing tool (Dovetail SchemaEditor, or ddcomp) to perform schema changes, use an import tool (such as Dovetail ArchiveManager, or dataex) for importing forms, and then compile your Clearbasic code using CBEX, or just import it as a DAT file using Dovetail ArchiveManager. File copying, registering components, configuring web servers, and setting permissions are all common tasks that are available in these build tools as well.   Should you also need to do additional stuff in your database, some code that uses the Dovetail SDK can be useful.   You could tie this…

A few of my common utilities

March 20, 2008 Whenever I have to do something more than a few times, I like to make a shortcut or a utility for it. I have all of these in my c:\bin directory, and I have my system path set to include c:\bin.  These utilities mean that I don't have to think about a lot of heavy syntax most of the time.   For example, to import a DAT file into my database, rather than using:   c:\bin\diet.exe -license MyDietLicenseKey -user_name sa -password sa -db_server . -db_name dovetail -import file.dat -sqllog sql.log     I just have to use:   import dovetail file.dat     Much easier to remember, and much easier and quicker to type.   Most of these are geared towards running on my development system, which is primarily SQL Server running onlocalhost with an sa password of sa.   Here's a few common…

Migrate a business rule from one database to another

November 13, 2007 I was working with a customer today, and they mentioned that one task that is problematic for them is moving business rules from their test database into the production database. Currently, the business rule is manually created via the Clarify Client in the test instance, and then when its all working, it is then again manually re-entered into the production. Manual re-entry is a point of potential failure. The rule may have been perfect in test, but a simple typo when re-entering it in production can cause havoc.One solution to this issue is to archive the business rule using ArchiveManager or dataex from the test database, and then use ArchiveManager or dataex to import it into production.Business RuleFirst, I created a new business rule in my test system:Object Type:CaseRule Name/Description:New Employee RequestStart Event:DispatchCancel Events:NoneConditions:Case Type = New EmployeeAction Title:Create SubcasesMessage…