DWUTKA at marlow.com
DWUTKA at marlow.com
Tue May 25 17:32:09 CDT 2004
I think JC is agreeing with me on this, and I think you have a disconnect on what is a necessary limit, and what is an arbitrary limit. 255 characters is a necessary limit. It is set by the fact that a text field is defined to take up from 1 to 256 bytes. 1 byte is for the size actually stored, the rest leaves up to 255 characters of space. That is built into Jet. The only way around that limit is to either 'join' two or more text fields together (which I have done on RARE occasions), or use a Memo field. Memo fields can hold quite a bit more, however, there are drawbacks with Memo fields. However, the line between when to use one or the other is pretty clear. Is the field in question a data point, or is it a storage bin? In other words, is the field going to represent one particular fact? If it is a single fact, yet it may go over 200 characters, then either a second text field needs to be defined for carryover, or a memo field should be used. 20 characters for an address field is an arbitrary limit. An assumption is made that no more then 20 characters is going to be used for that field. It is not a necessary limit. You may set a textbox to a particular size, but the textbox can be changed with little fuss. Let's say you put gas in your car once a week. Would you only put in the amount you expect to use for the week, or would you completely fill your tank? If you only put in what you expect to use, if something UNEXPECTED happens, you'll run out of gas, which is exactly what you do to your users if you set arbitrary limits. They'll be driving along, cruising down the data entry highway, then they'll realize they need to take a detour. Detour is taken, and kaput, their system runs out of gas, so they have to call the tow-truck developer to come give them more gas to get home. If they go on longer trips then what a normal car can hold, they need to buy a bigger gas tank (or compress the data, and get a more efficient car). You want to provide your users with a full tank. Filling the trunk with extra gas cans, having a tanker drive beside them, or converting them to nuclear power is going to be overkill, unless they want to run forever without refueling. But that would be in the clients specs, wouldn't it? If you give the users a full tank, and the client expects them to only go 100 miles, if their going off course to see their grandmother, or making trips to a strip club, or whatever, that is the Clients responsibility to monitor their users, not yours. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Scott Marcus Sent: Tuesday, May 25, 2004 4:58 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various <<Might as well move them to a SQL server, that is hacked into every computer system in the world, to get as close to unlimited drive space. You just made my point. There are limits, but your argument is "lets not limit the data entry" because you somehow get burned on its size later. I'm not being theatrical just realistic. ________________________________ From: accessd-bounces at databaseadvisors.com on behalf of DWUTKA at marlow.com Sent: Tue 5/25/2004 4:47 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various No, because 'not limiting the size' isn't changing the data type. Memo fields do not act like text fields. There is a difference. Ever try to group a memo field in a query? <grin> Not too mention, if you want to argue that, then let's go all the way. Memo fields are limited to 64k, or the db size limit, if edited through code. So in 97 you're talking 1 gig, and 2k+ you are talking 2 gig. Might as well move them to a SQL server, that is hacked into every computer system in the world, to get as close to unlimited drive space. Let's not cheapen this issue with bad theatrics. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Scott Marcus Sent: Tuesday, May 25, 2004 12:38 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various But you are arbitrarily limiting them. In this case to 255. So I'm back to saying you should set it to memo if you really feel this way. 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: Tuesday, May 25, 2004 1:32 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various Scott, I am not being ridiculous nor taking it personally. I do everything I do for a reason. I question everything. If I am told to make a field 20 characters I want to know why. If I am told not to run my tires under 28 lbs I want to know why. There are reasons for rules, and it is important to understand WHY the rule exists. You cannot make intelligent decisions on when a rule can safely be broken or ignored if you don't understand the reason it exists to begin with. I see no reason for arbitrarily limiting my users text fields, and you can't tell me that "I limit the address field to 25 characters" isn't arbitrary, it absolutely is. Pick a number out of thin air and that's what is being used. It simply isn't my business, it is their business. John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Scott Marcus Sent: Tuesday, May 25, 2004 12:07 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various Now you are being ridiculous. These are just examples. I think you would rarely run into and address line greater than 50, but that's not the point. There are things like the backend up grader to do these jobs for you. Don't take it personal, I just find this an interesting and entertaining topic. 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: Tuesday, May 25, 2004 11:55 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various Scott, you apparently have the benefit of unlimited freedom in your database, sitting on site all day just waiting for your users to ask you to expand a field. I have NO client closer than 45 miles from my office. Some are in other states. Of course I'll just jump on a plane and go do that. Or walk the client through doing it. In any case, boot all the users while I do it. And of course they can't enter the data until I do. Hmmmm.... sounds like a curious definition of customer service. Why do I care if they enter 50 characters in the address2 field? If that is what the address is, then they need to be able to enter that. The chance that it will be > 255 is so small that it isn't worth discussing so why are discussing it? The chances that it will be bigger than 25 are pretty good. My job is to design a database that requires as little intervention on my part as they can get away with. I charge them by the hour to increase the size of the field. Come to think of it, I suppose I should just start with all fields at 10 characters and let the money pour in as I go back time and again to "increase the field size". Sounds rather silly when stated that way doesn't it? And what is the benefit? What have you gained? (other than LOTS of extra money increasing field sizes) The person also mentioned that if you are allowing your users to directly enter two digit state codes you have bigger problems than field lengths. John W. Colby www.ColbyConsulting.com -- _______________________________________________ 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 -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com