Scott Marcus
marcus at tsstech.com
Tue May 25 06:37:58 CDT 2004
<< Just today I had to go in and remove a mask that the client requested. When I designed the db the client swore up and down that they would NEVER have claimants residing outside the US. They did NOT want a country field, they wanted a US state table etc. I explained the obvious and gave them what they asked for. Today I removed the zip code mask so that a Canadian zip could be entered. The 2nd line of the address is being used for the city and country. Why is it such a big deal to go and make the change? That's why they pay you. What if the maximum for a text field was 512? Would you then set the limit to 512? Scott Marcus TSS Technologies, Inc. marcus at tsstech.com (513) 772-7000 -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby Sent: Monday, May 24, 2004 8:59 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various Brett, >If you always allow 255 characters for your text fields, do you format your forms and reports to display that size of data? I format forms to accept as much as is normally needed plus some, taking in to account screen real estate. You can always scroll left / right or even add scroll bars to text boxes to allow vertical scrolling as needed. In reports I use AllowToGrow so that the box can expand vertically as needed. >Of course, I'm assuming that you don't display all 255 characters. On forms that is obviously true, on reports it is false. >Have you ever encountered users that misuse the fields? Of course. >Doesn't allowing the entry of 255 characters in any text field (say Address 2) invite the careless user to treat it as the Memo field they forgot to ask for? Yes. OTOH, how do you handle it? OK, lets not make it 255, let's make it what.... 25? What happens when they really do need 26? OK, if not 25, then what? 50? You are making an arbitrary decision, running the risk of a valid address not fitting (and I've seen some pretty big ones) or, if you expand to 50, then allowing the user a short memo anyway. I cannot set the rules for the user, the client needs to do that. If the client does not want the user using Address2 as a memo field they need to state that. If the user uses Address2 as a memo field then the client needs to discipline their employee. My job is to allow the user to capture the data, whatever that data might be. My job is NOT to tell the user "make it fit in 20 spaces". IF the client asks me to set up a zip code mask, or a phone mask or whatever I will do so. That is the CLIENT requesting it. If the client requests that I set Address2 to 20 characters then I will do so, because the CLIENT asks me to. I will state the argument that the address might be longer than 20, explain that in the event they encounter an address longer than the limit they will have to get all the users out of the db (or at least out of that table) in order to modify things so that the address fits. If they want 20, then they get 20 but I am never going to arbitrarily make such a decision. If the data MUST be limited, or checked in some way, for a valid business rules reason, I will do that. But that is fundamentally different from arbitrarily "deciding" on 20 (or whatever) characters. I certainly do not agree that it is sloppy programming (db design). Just today I had to go in and remove a mask that the client requested. When I designed the db the client swore up and down that they would NEVER have claimants residing outside the US. They did NOT want a country field, they wanted a US state table etc. I explained the obvious and gave them what they asked for. Today I removed the zip code mask so that a Canadian zip could be entered. The 2nd line of the address is being used for the city and country. I explained the obvious and was explicitly told NOT to give them what they ultimately needed. No way in hell I am going to INTENTIONALLY not give them what they need just because I personally think an address should fit in 25 (or whatever) characters. John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Brett Barabash Sent: Monday, May 24, 2004 1:22 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various I've been watching this thread for a while now, and need to ask this question to Drew and JC: If you always allow 255 characters for your text fields, do you format your forms and reports to display that size of data? Drew, you talk about being "burned by these limitations". It would seem to me that if your report's fields are not wide enough and truncate the field contents, you have effectively imposed that limitation. However, you have done it in a much more insidious way, by allowing the user to type in a long string and then not displaying its full contents in the output. This seriously breaks one of my cardinal design rules of accepting user input that the system is not able to process. Of course, I'm assuming that you don't display all 255 characters. If my assumption is wrong and you actually do leave enough room for all 255, doesn't this result in pretty weird looking tabular reports? How many 255 character fields can you fit across an 8 1/2 X 11" piece of paper? 1? 2 perhaps? Have you ever encountered users that misuse the fields? I have (in almost every company I've worked for). Doesn't allowing the entry of 255 characters in any text field (say Address 2) invite the careless user to treat it as the Memo field they forgot to ask for? Seems like sloppy programming to me. And very surprising comments from developers who preach about following good data modeling practices. -----Original Message----- From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com] Sent: Friday, May 21, 2004 1:54 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various I think we are talking apples and oranges here. Yes, the page file size needs to be taken into consideration. I set all of my text fields to 255. I do this because I don't want to be backed into a wall, because I set a size limit that prevents a user from entering what they need to enter. If I provide a phone number field, and set it to 10 (area code and phone number), sure, I am 'limiting' the client. However, what happens when they want to put in an international number. Or if the US decides to move to 8 digit phone numbers. Who knows, there are all sorts of reasons that the field size may change. Now, if I have some sort of logic checking data integrity, that would have to be changed, but if I don't, by having the field size set to 10, I am limiting the users at the table level, to a point where they cannot do their job. If I have it set to 255, I am 99.99999% they would never put 255 characters into that field, but they may put in 11, or 12, etc. Oh well, this really isnt' something I feel like arguing about. I see your point Jürgen, but this is really a case of who has been burned and how. I have been burned over and over by previous developers putting such limitations into their databases. I have never been burned by the page file size. In fact, I completely forgot that the limit even existed, until it popped up on the list a few weeks ago. So that is why I set my default text field size to 255. Drew ---------------------------------------------------------------------------- ---------------------------------------- The information in this email may contain confidential information that is legally privileged. The information is only for the use of the intended recipient(s) named above. If you are not the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or the taking of any action in regard to the content of this email is strictly prohibited. If transmission is incorrect, unclear, or incomplete, please notify the sender immediately. The authorized recipient(s) of this information is/are prohibited from disclosing this information to any other party and is/are required to destroy the information after its stated need has been fulfilled. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Tappe Construction Co. This footer also confirms that this email message has been scanned for the presence of computer viruses.Scanning of this message and addition of this footer is performed by SurfControl E-mail Filter software in conjunction with virus detection software. -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com