Re: Multiple Response Field

Ian,

I strongly recommend avoiding multiple response fields, although I have used
them in an application successfully. Treat them like arrays. In native Superbase
there is a key stroke I forget for changing elements within the field. But these
will not be easy to work with when you want to move data to another format, for
example.

Off the top of me 'ead, much better to use more fields, make them
"logical" and put in checkboxes to mark them:

john
  [x] grp1 (clients)
  [x] grp2 (suppliers)
  [ ] grp3 (accounts)
mary
  [x] grp1 (clients)
  [ ] grp2 (suppliers)
  [x] grp3 (accounts)
peter
  [ ] grp1 (clients)
  [x] grp2 (suppliers)
  [x] grp3 (accounts)
henry
  [x] grp1 (clients)
  [x] grp2 (suppliers)
  [x] grp3 (accounts)

And maybe a calculated field that combines the group fields:
  FRM grp1 + grp2 + grp3

Then your header file can have fields like this linked to the calc field:
clientssuppliers
  - john

clientsaccounts
  - mary

suppliersaccounts
  - peter
  - henry

clientssuppliersaccounts
  - henry

To make it pretty you can display a field in the header file that is more
sensible, and hide the concatenated one:

Clients, Suppliers and Accounts
  - henry






Do I understand your project?

Peter


On Thu, 02 Feb 2006 16:02:57 -0500, Ian Stephenson <ian@soeasy.co.nz>
wrote:

> KiaOra everyone
>
> Our database currently has a field used to group the clients. we then
filter
> the Clients Group and work with that group
>
> e.g.
>
> John    Group CLIENTS
> Mary   Group SUPPLIERS
> Peter   Group CLIENTS
> Paul     Group CLIENTS
> Henry  Group ACCOUNTANS
>
> I need to provide a multiple grouping scenario
>
> e.g.
> John    Group CLIENTS, ACCOUNTANTS
> Mary   Group SUPPLIERS
> Peter   Group CLIENTS, ACCOUNTANTS
> Paul     Group CLIENTS
> Henry  Group ACCOUNTANS
>
> The best way I can see to do this is with a Multiple Response Field.
> I have set it to 10 but I cant find out how to use it.
>
> 1. How would I add a new Group Classification to a client who already has
a
> group?
>
> 2. How would I display the Multiple Responses?
>
> 3. How would I edit/delete an individual group form a clients record?
>
> Thanks for your help :)
>
> Regards
> Ian
>
>
>
>



-- 

KiaOra everyone

Our database currently has a field used to group the clients. we then filter 
the Clients Group and work with that group

e.g.

John    Group CLIENTS
Mary   Group SUPPLIERS
Peter   Group CLIENTS
Paul     Group CLIENTS
Henry  Group ACCOUNTANS

I need to provide a multiple grouping scenario

e.g.
John    Group CLIENTS, ACCOUNTANTS
Mary   Group SUPPLIERS
Peter   Group CLIENTS, ACCOUNTANTS
Paul     Group CLIENTS
Henry  Group ACCOUNTANS

The best way I can see to do this is with a Multiple Response Field.
I have set it to 10 but I cant find out how to use it.

1. How would I add a new Group Classification to a client who already has a 
group?

2. How would I display the Multiple Responses?

3. How would I edit/delete an individual group form a clients record?

Thanks for your help :)

Regards
Ian

Neil,

If Ian is considering multiple response fields, with only ten elements max, just
adding ten extra LOG fields won't be much overhead, and the calculated field
will make a string that the header can deal with easily. That would all be
invisible to users and self-maintaining. But I may have misunderstood what he
wants to display.

I use three files and two detailblocks on two pages of a form, and the list of
categories is below the individual records. But this does require considerable
programming to accomplish, and you must also handle changes that  propagate
through the hierarchy.

But you are correct, of course, in your suggestion.

Peter


On Fri, 03 Feb 2006 10:20:17 -0500, Neil Robinson <neilr@superbase.co.uk>
wrote:

> Peter Barus wrote:
>> Ian,
>>
>> I strongly recommend avoiding multiple response fields, although I
have
>> used them in an application successfully. Treat them like arrays. In
>> native Superbase there is a key stroke I forget for changing elements
>> within the field. But these will not be easy to work with when you
want
>> to move data to another format, for example.
>>
>> Off the top of me 'ead, much better to use more fields, make them
>> "logical" and put in checkboxes to mark them:
>>
>> john
>>  [x] grp1 (clients)
>>  [x] grp2 (suppliers)
>>  [ ] grp3 (accounts)
>> mary
>>  [x] grp1 (clients)
>>  [ ] grp2 (suppliers)
>>  [x] grp3 (accounts)
>> peter
>>  [ ] grp1 (clients)
>>  [x] grp2 (suppliers)
>>  [x] grp3 (accounts)
>> henry
>>  [x] grp1 (clients)
>>  [x] grp2 (suppliers)
>>  [x] grp3 (accounts)
>>
>> And maybe a calculated field that combines the group fields:
>>  FRM grp1 + grp2 + grp3
>>
>> Then your header file can have fields like this linked to the calc
field:
>> clientssuppliers
>>  - john
>>
>> clientsaccounts
>>  - mary
>>
>> suppliersaccounts
>>  - peter
>>  - henry
>>
>> clientssuppliersaccounts
>>  - henry
>>
>> To make it pretty you can display a field in the header file that is
>> more sensible, and hide the concatenated one:
>>
>> Clients, Suppliers and Accounts
>>  - henry
>
> Pete,
>
> probably better is to simply use a secondary file. Multiple response
> fields are a definite no, no of course. The problem with the approach
> that you outlined is that you end up needing to add a field everytime
> you have a new category, and that overhead is carried by every record.
> Better is to use a secondary database table. That means that you can
> show as many or as few categories as you wish. It does slightly
> complicate queries since you need to run multiple selects and store the
> record IDs of the interim results, but it can be done. Using v2 is
> harder for this because you don't have sets. Sets make this sort of
> thing much easier.
>
> Ciao, Neil
>



-- 

Peter Barus wrote:
> Ian,
> 
> I strongly recommend avoiding multiple response fields, although I have 
> used them in an application successfully. Treat them like arrays. In 
> native Superbase there is a key stroke I forget for changing elements 
> within the field. But these will not be easy to work with when you want 
> to move data to another format, for example.
> 
> Off the top of me 'ead, much better to use more fields, make them 
> "logical" and put in checkboxes to mark them:
> 
> john
>  [x] grp1 (clients)
>  [x] grp2 (suppliers)
>  [ ] grp3 (accounts)
> mary
>  [x] grp1 (clients)
>  [ ] grp2 (suppliers)
>  [x] grp3 (accounts)
> peter
>  [ ] grp1 (clients)
>  [x] grp2 (suppliers)
>  [x] grp3 (accounts)
> henry
>  [x] grp1 (clients)
>  [x] grp2 (suppliers)
>  [x] grp3 (accounts)
> 
> And maybe a calculated field that combines the group fields:
>  FRM grp1 + grp2 + grp3
> 
> Then your header file can have fields like this linked to the calc field:
> clientssuppliers
>  - john
> 
> clientsaccounts
>  - mary
> 
> suppliersaccounts
>  - peter
>  - henry
> 
> clientssuppliersaccounts
>  - henry
> 
> To make it pretty you can display a field in the header file that is 
> more sensible, and hide the concatenated one:
> 
> Clients, Suppliers and Accounts
>  - henry

Pete,

probably better is to simply use a secondary file. Multiple response 
fields are a definite no, no of course. The problem with the approach 
that you outlined is that you end up needing to add a field everytime 
you have a new category, and that overhead is carried by every record. 
Better is to use a secondary database table. That means that you can 
show as many or as few categories as you wish. It does slightly 
complicate queries since you need to run multiple selects and store the 
record IDs of the interim results, but it can be done. Using v2 is 
harder for this because you don't have sets. Sets make this sort of 
thing much easier.

Thanks for your input.
The goal for the multiple reponse is for marketing purposes. We need to be 
able to classify a database entry as belonging to multiple marketing groups.

The logical field would work but it is hard to specify how many groups a 
client may require.
We already use this technique for client classification in other areas and 
it works well.
(I must also point out we compete with ACT, Sage, MYOB, and Quick Books so 
marketing is a very important strength we require.)

The separate file is also a great method and I think in this circumstance we 
will use it as it has no limit. Our marketing functions allow a user to 
define a filter and then a procedure flags matches in the database and 
returns the result.

Thanks guys

"Peter Barus" <peter@visualpricing.com> wrote in message 
news:op.s4eq96wepcvzm2@tetsumaru...
> Neil,
>
> If Ian is considering multiple response fields, with only ten elements 
> max, just adding ten extra LOG fields won't be much overhead, and the 
> calculated field will make a string that the header can deal with easily. 
> That would all be invisible to users and self-maintaining. But I may have 
> misunderstood what he wants to display.
>
> I use three files and two detailblocks on two pages of a form, and the 
> list of categories is below the individual records. But this does require 
> considerable programming to accomplish, and you must also handle changes 
> that  propagate through the hierarchy.
>
> But you are correct, of course, in your suggestion.
>
> Peter
>
>
> On Fri, 03 Feb 2006 10:20:17 -0500, Neil Robinson
<neilr@superbase.co.uk> 
> wrote:
>
>> Peter Barus wrote:
>>> Ian,
>>>
>>> I strongly recommend avoiding multiple response fields, although I
have
>>> used them in an application successfully. Treat them like arrays.
In
>>> native Superbase there is a key stroke I forget for changing
elements
>>> within the field. But these will not be easy to work with when you
want
>>> to move data to another format, for example.
>>>
>>> Off the top of me 'ead, much better to use more fields, make them
>>> "logical" and put in checkboxes to mark them:
>>>
>>> john
>>>  [x] grp1 (clients)
>>>  [x] grp2 (suppliers)
>>>  [ ] grp3 (accounts)
>>> mary
>>>  [x] grp1 (clients)
>>>  [ ] grp2 (suppliers)
>>>  [x] grp3 (accounts)
>>> peter
>>>  [ ] grp1 (clients)
>>>  [x] grp2 (suppliers)
>>>  [x] grp3 (accounts)
>>> henry
>>>  [x] grp1 (clients)
>>>  [x] grp2 (suppliers)
>>>  [x] grp3 (accounts)
>>>
>>> And maybe a calculated field that combines the group fields:
>>>  FRM grp1 + grp2 + grp3
>>>
>>> Then your header file can have fields like this linked to the calc

>>> field:
>>> clientssuppliers
>>>  - john
>>>
>>> clientsaccounts
>>>  - mary
>>>
>>> suppliersaccounts
>>>  - peter
>>>  - henry
>>>
>>> clientssuppliersaccounts
>>>  - henry
>>>
>>> To make it pretty you can display a field in the header file that
is
>>> more sensible, and hide the concatenated one:
>>>
>>> Clients, Suppliers and Accounts
>>>  - henry
>>
>> Pete,
>>
>> probably better is to simply use a secondary file. Multiple response
>> fields are a definite no, no of course. The problem with the approach
>> that you outlined is that you end up needing to add a field everytime
>> you have a new category, and that overhead is carried by every record.
>> Better is to use a secondary database table. That means that you can
>> show as many or as few categories as you wish. It does slightly
>> complicate queries since you need to run multiple selects and store
the
>> record IDs of the interim results, but it can be done. Using v2 is
>> harder for this because you don't have sets. Sets make this sort of
>> thing much easier.
>>
>> Ciao, Neil
>>
>
>
>
> -- 
> "Oboslete power corrupts obsoletely" - T.H. Nelson