InfoQube IM - Community

Submitted by mjwilliamsmj on 2011/03/06 20:28

The 1. Introduction states :

"Manage your contacts and sale leads using the AddressBook:

Enter as little or as much details as you wish for each contact. No limits to the number of email adresses and phone numbers"

Does this imply multi-line entries for multiple telephone numbers?

OR, maybe multiple children telephone entries?

The statement is clear but the implementation is fuzzy.

I d not know what is implied.

Mike

Comments

[quote=mjwilliamsmj]The 1. Introduction states :

"Manage your contacts and sale leads using the AddressBook:

Enter as little or as much details as you wish for each contact. No limits to the number of email adresses and phone numbers"

Does this imply multi-line entries for multiple telephone numbers?

OR, maybe multiple children telephone entries?

The statement is clear but the implementation is fuzzy.

I d not know what is implied.

[/quote]

Hi Mike,

I'm afraid I cant say what is implied - both are possible but multi-line entries (in the one field I mean) may have drawbacks.

Hmm, I just tested:

with three email addresses in the email field - when I click on one of the addresses, three (Thunderbird) windows open - one for each address.

I wonder could this behaviour be changed Pierre? (or given a qualifier key?)

BTW, not directly related to your question, but have you seen 1. Grid Display Modes

Hi Tom,

Yes, I have reviewed 3.2.40.

If the statement as quoted were not in context of the "Address Book" (supplied example), I would have "assumed" that multiple field properties could be assigned to a contact.

However, this would be wasteful from a database design view. Database "normalization" is a process to reduce the size of a RDBMS.

Normalization for multiple telephone numbers per contact, would have the telephone numbers in a separate database from contacts. That way contacts would be in a one-to-many relationship with telephone numbers, and each contact would only have as many entries in the telephone database as required. If the telephone numbers were multiple fields in the contacts database, those field would exist whether used or not, and increase the database size unnecessarily!

Not knowing the underlying design of InfoQube, I do not know if "normalization" is an applicable process.

Getting away from the "Address Book" example, I would have contacts, and create telephone numbers as children. This would be similar to "normalization" in RDBMS.

Mike

Hi Tom,

>with three email addresses in the email field - when I click on one of the addresses, three (Thunderbird) windows open - one for each address.

Can you explain the steps ? Because when I try it, only one window opens, with the correct email address.

[quote=Pierre_Admin]

Hi Tom,

>with three email addresses in the email field - when I click on one of the addresses, three (Thunderbird) windows open - one for each address.

Can you explain the steps ? Because when I try it, only one window opens, with the correct email address.

[/quote]

yeah, I did a shift+return after each email.

Is reproducible in the sample file here

Hi Mike,

There are a number of ways to add phone numbers to an item :

As separate fields
In the same field, separated by a delimiter
As part of the item text
In the HTML pane
As sub-items

The dialer will find all of these except for #5 (support for this is planned)

For email adresses, you can use :

As separate fields
In the same field, separated by a delimiter (the bug reported by Tom will be fixed)
As hyperlinks in any text field or in the HTML pane
As hyperlinks in sub-items

Regarding the use of separate fields, no need to worry about wasting space in the database. If IQ is based on a relational database, IQ fields are not fields in a database. What IQ does is to transform it to a column-oriented database.

HTH