DWUTKA at marlow.com
DWUTKA at marlow.com
Tue May 25 13:00:24 CDT 2004
I don't know Gustav, I don't charge my clients if I think I should have programmed something differently. Just recently, I wrote a PO and an Inventory system as a sub contract job. System works great, until they used part descriptions that had double quotes in them. It was a simple fix, had two SQL strings where I just wrapped the offending field in a Replace statement. Problem solved, and no charge (to the actual 'contractor'). Why? Because I guarantee my work. They asked for a system, and I met their specs. My system failed on something that was not outside of the original specs. So, if I write a system that limits a field to 20 characters, because I am 'guessing' that is all they'll ever need, and one day they come back and say, hey, your system won't let us put in the data we need to put in, I would could consider that a warrantee job, because I put a limit that the customer didn't ask for. Now, if the customer puts in their specs, that a particular field is not to go over 20 characters, well, honestly, I wouldn't limit the field, still, I would just force the interface to not allow more then 20 characters. Again, I usually write ASP front ends, so in this case, I would have the code, that enters or modifies the data in the db, use a Left(strXYZ,20) statement, to chunk anything over that shows to be longer then 20 characters. If the client later changes the requirement to 25 characters, I just change my code to allow for more characters, and bill them for the change. It is also a different world with web clients. Something I better bring up. It is a LOT easier to change your code, then to make structural changes in a web database. Code changes can be made to a live system, with little to no interruption. (If it's using ActiveX .dll's, there is going to be a few seconds of down time, to release the old .dll, and replace it with the new one). If it's using just ASP, there is absolutely no down time, the next person to use the system after the update gets the new page. However, it is a rare case that you have direct access to the webserver, and even rarer that it would have Microsoft Access on it. So you either write some complex SQL statements to create a temp table with the change, delete the old table, and then create a new one in it's place with the temp table's data. OR, you turn their webserver off, download the database, make your change, and upload it back....can take a while depending on the size of the db. You'd have to turn their webserver off, because if you copy the 'new' db over the old one, and someone has used the system in the meantime, you are now replacing the current db with a new structure, but out of date data. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Gustav Brock Sent: Tuesday, May 25, 2004 8:30 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] On DB Bloat, Bad DB Design, and various Hi Stuart well, you and several contributors to this thread - with Arthur and Scott as the bright exceptions - should join a club of weeping school girls. Now come on and get professional as is the general attitude of our fellow listers. If you design an app wrongly, you'll of course have to fix it; if some standard is changed, say postal codes for a country goes from x to y format and you couldn't know, the client has to pay. If your app is out in big numbers, you would offer an update. Since when has distributing an update been a problem? /gustav > On 25 May 2004 at 7:45, Scott Marcus wrote: >> >> Someone else mentioned not limiting fields to 2 letters for state >> abbreviations. Why not? When the abbreviations jump to 3 letters, I'll >> make the field bigger. That's just part of my job. >> > And who pays for that work to be done? > Do you stick the client with a bill for a modification that > shouldn't have been needed or do you wear the cost of the time > yourself. > What if you've got the same app rolled out in lot's of different > places. It can get quite expensive to provide updates to all the > sites. -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com