Community
Showing results for 
Search instead for 
Do you mean 
Reply

Discovered "bug" while copying a contact

New Member
Posts: 5
Country: Germany

Discovered "bug" while copying a contact

Hi everybody, I've discovered a very strange behaviour of ACT!11 Premium.
We've bought the SA-password once during our migration from ACT!6, so I was able to find this "bug".

Some background information:

We used the migration wizard to convert the ACT!6 DB to ACT!11. During this migration the wizard created a
new table called "CUST_KontaktTabelle1_072810". The table contains some fields added by an ancient
ACT!6 plugin. I saw that some of the custom-fields (created by the old plugin) are stored
in the custom-table mentioned above, some other are stored in the contact-table (TBL_CONTACT).

We've created more custom fields during the migration, which where all stored in TBL_CONTACT.
After the migration we've created even more fields Smiley Wink These are stored in the custom table.
We had to create these fields to work around some bugs in ACT! (The countrycode was not displayed on contactreports)
I've created a trigger on TBL_PHONE, which is fired after an update or insert. The trigger assembles
the phone number incl. countrycode. The trigger checks whether a new relation needs to be created
or an existing relation needs to be updated and performs the corresponding action.

To ensure that all phone numbers are displayed correctly, I've used a cursor to update the field which holds
the phone number displayed on each contact report.

--------------------
Lets sum up:

We have created a huge amount of custom fields in ACT!6 and ACT!11. A custom table was created during the migration.
Some custom fields are added to the custom table, some added to TBL_CONTACT. I've created some triggers which
ensure that the correct phone number is displayed on a contact report, that a valid delivery address is added to
 to the packing slip. This causes that _every_ CONTACTID is present in the custom table.

--------------------
Some more background:
I've added two more fields to the database:
- one field was added to the custom table,
- the other on was added to TBL_CONTACT

--------------------
Now the bug:

I've copied a valid contact, which includes companyname, department, address, etc. ACT displays the new
contact, but editing any of the fields forces ACT! to fail with a message, which tells that the contact
is not present in the database.
Well this is quite right. I've sniffed the queries which will create the contact. One of them fails:

"INSERT INTO dbo.CUST_KontaktTabelle1_072810 (CUST_a11_Erstkontakt_Details_014320337, CONTACTID) VALUES (N'E-Mailingaktion', '5d7494f9-a262-41c8-8abb-1179974fabe8')"

This will fail due to the presence the PK (CONTACTID) in the custom table.

So the bug is:
ACT! does not check if the PK is present in the table.

And the strange behaviour is that ACT! does not follow any kind of "rule" where custom fields are created. Seems
fuzzy to me Smiley Sad

----------------------------------------------------------------

Here are some Reports from ACTDIAG:

Taken from "Database Objects Detail Report":

Schemaversion:                          11.01.0178.0000
Schemadatum:                            2010-07-30T17:44:40.660
Vorherige Schemaversion:                11.00.0348.0000

TABLE                                   DOMAIN                   CREATEDATE                   EDITDATE                 CREATED BY
-----                                   ------                   ----------                   --------                 ----------
CUST_KontaktTabelle1_072810             Contact                  2010-05-07 19:28:10.353                               Converter

----------------------------------------------------------------

Taken from "Datebase Fields Detail Report":

    ACT! Table: Kontakt Tabelle 1
Physical Table: CUST_KontaktTabelle1_072810
  Record Count: 29240
 Created On/By: May  7 2010  7:28PM / Converter
   Field Count: 9 (9 Physical, 0 Virtual, 0 Calculated)
(in approx. bytes) Supported Pagesize: 7584, Current Pagesize: 816, Available Pagesize: 6768

    ACT! Table: Kontakt
Physical Table: TBL_CONTACT
  Record Count: 29240
 Created On/By: Aug  1 2008  2:02AM / ACT! System
   Field Count: 124 (82 Physical, 41 Virtual, 1 Calculated)
(in approx. bytes) Supported Pagesize: 7584, Current Pagesize: 7537, Available Pagesize: 47

Employee
Posts: 1,163
Country: USA

Re: Discovered "bug" while copying a contact

Just to make sure I'm clear on this, to reproduce this I should:

 

1. Create a new contact

2. Attempt to insert data into a field for the newly created contact

Matthew Wood
Act! SDK Support
Community Moderator
New Member
Posts: 5
Country: Germany

Re: Discovered "bug" while copying a contact

Hi,

 

sorry for the delayed response.

 

Yes, this will cause an error on our database. I guess you won't face any problems.

New Member
Posts: 5
Country: Germany

Re: Discovered "bug" while copying a contact

Let me add an example to make things clear:

 

I assume that the following tables are involved in a "normal" database if a contact is added:

TBL_CONTACT

TBL_ADDRESS

TBL_EMAIL

TBL_PHONE

 

And in my case the mentioned table:

CUST_KontaktTabelle1_072810

 

Additionally the following triggers are fired during the INSERT and/or UPDATE processes:

trg_HTZ_UpdateMailAddressFields (AFTER INSERT, UPDATE) on TBL_ADDRESS

 - will add/update the given address to CUST_KontaktTabelle1_072810

 

trg_HTZ_ContactReportPhone (AFTER INSERT, UPDATE) on TBL_PHONE

 - will add/update the given phone number to CUST_KontaktTabelle1_072810

------------------------------------------------------------------------------------------------------------------------------------

 

The user has to fill in most of the fields. During the INSERT process at least one trigger is fired and will insert or update a (new) row in CUST_KontaktTabelle1_072810.

 

If I copy a valid contact ACT! tries to insert a new row into CUST_KontaktTabelle1_072810, where the PK is already present. This will force ACT to fail.

 

-------------------------------------------------------------------------------------------------------------------------------------

 

I've created an image to visualise the case.

 

 

Hope this will light the case up a bit.

 

Kind Regards,

 

Alex