Scott Marcus
marcus at tsstech.com
Thu May 27 16:29:05 CDT 2004
On the flip side, Drew. If the client had the field size set to the max and was only using a very small portion of that max and then suddenly started using a large portion of that field(because a business rule changed), you may have problems with complex reports that take way more than 1 & 1/2 hours to fix. You may also have other issues, like database growth that wasn't planned for. I know I'm reaching, just curious. One abuse I can think of was a client that started putting in Husband and Wife names into the firstname field (that I set at 50 characters). This caused mailing and invoice problems as well as office confusion. Sure, you may say that this is a training issue, but they did it because it worked around a new business requirement that the program lacked. In most cases, their work around didn't cause a problem. When it did cause a problem guess who got the blame? The client only calls when there are problems. It doesn't matter if it's a field being too small or too big. 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 DWUTKA at marlow.com Sent: Thursday, May 27, 2004 4:09 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] On DB Bloat, Bad DB Design, and various <snip> > WOW way to burn time... you obviously didn't have the right tools for the job, because if you can ADD and you can DELETE a field, then you can ALTER... and it takes no more than a few minutes, that's w/ the time it takes to find the field and either write up the command or use a gui interface to do it all... 2 fields, that's nothing, you were just using a hammer.... <snip> Actually, the 'web interface' tool, that their IT department let me have access to had Add and Delete LINKS. I then had a place to run querries. I couldn't tell if I could run 'scripts' or not. I used my 'copy' on my SQL server, to make a script to do the job. However, what I have at home is named differently, and I was 99% sure I didn't have all of the latest design changes, so I had two problems with trying to use a script to solve. One, I couldn't use the script MY Enterprise Manager created, without modifying it. And to modify it, I would have had to dig through all of the changes that were made to the current system. Two, I wasn't even sure if it would run a script. I said Query, not script. So I used the links provided, and query capabilities provided. I may not have had done the process perfectly. I'll definitely admit that. Of course, the correct way this should have been solved, is for their IT guy to go to the console with Enterprise Manager, and change the field properties and click okay. Work done. However, it was a live system. I was getting zero support from their IT department, so I used a method I was confident I wouldn't screw up their LIVE data with. <snip> >Now think about that, is setting a field size limit to something close to >where you think your client won't exceed worth $150 a pop? > > No it's not, and you ripped off your client. Sorry, but unless that's what you charged for just showing up, that's a rip. -- -Francisco No, I didn't rip off my client. It took me an hour and a half to fix a problem HE created. He knows it, I know it. Am I supposed to spend my time fixing his mistakes for free? There was somewhat of a time pressure involved, and I was handed a tool to 'work with' SQL Server that I had never had before. I didn't have any other access to their system. (I couldn't even create an ASP page to do what I wanted to do.) I only had access to this 'web tool'. So trust me, he got off light, with it only taking 1.5 hours. He had already spent FIVE hours trying to figure out how to do anything in that 'web tool'. Drew -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com