Re: Application Development

In article <DoHFsw.GIB@cix.compulink.co.uk> onlinedbc@cix.compulink.co.uk ("Malcolm Weallans") writes: >This message is extremely relevant to an issue I am involved in at this >time. > [snip] >> 5. What other critical points if any should we be examining? >My major piece of advice is that the client should ensure that the >developer provide them with a well-documented schema of the database. >Recently I have been training personnel from VARs, consultants, and >clients. They all have a different interpretation of what database >documentation the developer should provide. The developers do not want >to provide any database documentation as they say that it would encourage >the client to alter data through SQL, abd the clients want the >documentation as they want to write their own queries and reports. > >I would like to see this issue discussed more fully through this group so >that we can arrive at a documented standard provision. FWIW, I provide schema documentation on the basis that, if they know what they're doing, they'll find it out anyway. (dbschema, anyone? dbaccess??). So make a virtue out of necessity; teach then how & why the dictionary is put together if they're interested enough to ask. (In fact, in some assessment projects I've been asked to do, the FIRST thing I want to see is a dictionary with the FK-PK rules and constraints). We then emphasise that connecting ANY odbc compliant tool to an app in any mode other than read-only will immediately cause us to to take a very cynical view of data anomoly/error complaints. As for altering the schema, forget it. We won't support a site that does this. We *also* reserve the right to make schema alterations as we see fit, when we see fit. I can see this one getting contentious if users are building reports on the structure and you then change it, so it's worth being up-front about it so all parties know what risks they're running. Peter Wiley