>Yes, Craig is always correct :). And trust me I know that in this particular case my approach won't bite me.
>
>>Craig is still correct ;-)
>>If your estimation that it will not bite you later holds true, that is half-ok or good enough, but you might ask yourself why you have not enough ready-2-run code for picklist use cases.
>>
>>>To store the emails in separate rows I would have to create a child table. This will complicate the design where it is not really necessary. These - extra emails - will be used by only a few (or just one or two) customers. So adding a child table to store the emails, IMO, is overkill. But from your words that "SQL Server will only store what it needs to" do I understand that Varchar(max) will not add more load than, say Varchar(400)?
>>>
>>>>SQL Server will only store what it needs to, but I question the design. Why store them all in one row instead of separate rows?
>>>>
>>>>>Hi,
>>>>>
>>>>>I need to add a column to a table that will store a string of email addresses. I am trying to decide between making this field type Varchar(SomeNumber) or Varchar(max). I expect that there will be need to store, at most, 10 email addresses in this field. So I figure that on average each email will take 40 characters and 400 will give me enough length to store 10 emails. Another approach is to make this field Varchar(max) which, I understand, will give me pretty much unlimited length. But I am concerned that Varchar(max) adds some load to the SQL Server database or SQL Server itself and leaning towards just Varchar(number). Is my concern of Varchar(max) valid? Or what would you do?
>>>>>
>>>>>TIA

In earlier versions Axapta was saving addresses, e-mails and phone numbers at main customer table. Now Axapta saves addresses, e-mails and phone numbers at address tables. You have unlimited address, phone, mail space with different types (home, work, invoice ... addresses, home, car, cell, 2.nd home, 2.nd cell ... phone numbers ...). It a bit harder but flexier and good for data sizing.