Re: Replication
Date: Wed, 29 May 2002 13:25:44 -0400
Message-ID: <3CF50F18.DE364842_at_ids.net>
Graham Bellamy wrote:
>
> The Quote table itself wouldn't hold much info (Date, salesman, client, job site
> info...,around 15 fields), but I don't see how I could get away from duplicating
> everything that would cascade from a particular quote number, as I don't know which of the
> child records he would want to add/delete/edit. In your example there would be many items,
> which would have to be duplicated, but in certain situations (mine included) each item
> could have many child records etc. In theory, that's a lot of duplication. Though in my
> situation, there's not a great amount of actual data being stored.
>
> Graham
>
> "David Kerber" <ns_dkerber_at_ids.net> wrote in message news:3CF3DC2E.77042956_at_ids.net...
> > How much data are you storing in the quote record itself? If it's just
> > pointers to customer ID's, with the customer details stored in a
> > different table, there's not much data being duplicated. Maintaining
> > the pointers to the child records is a bit more work, but if you break
> > up your quote info a bit more, you can handle it:
> >
> > tblQuotes
> > QuoteID AutoInc
> > QuoteNum String (Your 1001-1, 1001-2, etc)
> > SalesPerson Long
> > ...
> > Other info as needed
> >
> >
> > tblQuoteDetails
> > QuoteID Long
> > ItemID Long
> > Qty Integer
> > QuotedPrice Currency
> > ...
> > Other info.
> >
> > (with one record for each item on each quote)
....
-- Dave Kerber Edit the return address by removing the ns_ before e-mailing This message was entirely written using recycled electrons. REAL programmers write self-modifying code, leading to: Why there is ALWAYS one more bug (courtesy of O.D. Williams): 1. Debuging code is always much harder than writing it. 2. Therefore, if your code is as clever as you are capable of making it, you are, by definition, inadequate to debug it.Received on Wed May 29 2002 - 19:25:44 CEST