Re: Copy data from one table to another.

Re: Copy data from one table to another.

am 18.12.2007 18:06:36 von Phil Stanton

I think, Kevin that we need to clarify the terms we are using.

Normally this table

Description Reference Quantity Price ProjectID
>> Doors ABC 5 £25.00 1
>> Labour - 1 £500.00 1
>> Roofing Fred A 1 £6300.00 2 This
>> is a different project
>> Roofing Fred B 1 £3700.00 1

is refered to as a Bill Of Materials see
http://www.wisegeek.com/what-is-a-bill-of-materials.htm

I Understand an Estimate to be after adding all the lines together from the
BOM and addink markups etc., you come up with amount you are going to charge
your customerfor that project. Are you suggesting that you might produce the
same project usind different BOMs. E.G. You might do one quotation based on
buying in the basic components and assembling them yourself and a second
quotation based on buying in part assembled sub components. The beauty of
doing it the wat I suggested that is if on the BOM you include a date for
which the current price is valid and you are quoting for 2 different types
of house to 2 different customers, but both projects use the same doors (eg
Doors ABC at £25.00 each) then that entry need only occur once in the
database.

HTH Phil

"Kevin" wrote in message
news:liO9j.27200$WF3.26257@fe06.news.easynews.com...
> So what your saying is, rather than having an estimate table and a
> projects table that link back to the customer table, have the estimate
> table link back to the project table which links to the customer table?
> That seems an interesting idea, the only issue would be that I may create
> multiple estimates but in the end only one would need to be associated
> with the project and the rest would never be associated with any project.
> How would I handle those situations?
>
>
> "Phil Stanton" wrote in message
> news:13malh9o053a14b@corp.supernews.com...
>> If it were me, I would have a table for Customers, A table for projects
>> with the Project Title, description, type with your link back to the
>> customer table, and a table of estimtes linking back to the project
>> table.
>> It might contain data like
>>
>> Description Reference Quantity Price ProjectID
>> Doors ABC 5 £25.00 1
>> Labour - 1 £500.00 1
>> Roofing Fred A 1 £6300.00 2 This
>> is a different project
>> Roofing Fred B 1 £3700.00 1
>>
>> These would be set up in a subform of your projects form..Much more
>> mamageable
>>
>> Phil
>>
>>
>> "Kevin" wrote in message
>> news:2j_8j.122250$TD3.20305@fe05.news.easynews.com...
>>> Actually, I have a seperate customer tables with names, addresses and
>>> the like. The estimate table links to the customer table and then
>>> contains several key fields...project title, description, job type, and
>>> estimate price. It also contains a large number of input fields that are
>>> used to determine that estimate price. You are probably correct in your
>>> Excel comment. The majority of these input fields are not necessary once
>>> the estimate becomes a firm project and thus would only serve to clutter
>>> my projects table. Also, the estimate table will eventually contain
>>> fields for as many as 4 or 5 different types of job estimates and thus
>>> could potentially have 200+ fields while my project table is
>>> consideralbly smaller at 46 fields.
>>>
>>>> Tom is probably right, but the moment I see "a large number of data
>>>> fields" I suspect you are trying to create an Excel type sheet in
>>>> Access. I would guess that you should be looking at a main form for the
>>>> estimate (Names, Address etc) and a continuous subform showing details
>>>> and price. So 2 tables, one for the names and address and Tom's Status
>>>> flag and the other table with a foreign key pointing to the customer
>>>> and detail & price.
>>>>
>>>> Phil
>>>>
>>>> "Tom van Stiphout" wrote in message
>>>> news:1q88m3579783561fqvdaeplckfqnb75bki@4ax.com...
>>>>> On Sat, 15 Dec 2007 17:33:33 GMT, "Kevin" wrote:
>>>>>
>>>>> That's done with an Append query.
>>>>>
>>>>> But before you do that, consider carefully if your 2-table setup is a
>>>>> good idea. The alternative is one table, with an additional Status
>>>>> field that can be set to either Estimate or Job (or any number of
>>>>> statuses). This is often much more convenient.
>>>>>
>>>>> -Tom.
>>>>>
>>>>>
>>>>>>I need a little guidance here. I have set up a table for job estimates
>>>>>>with
>>>>>>a large number of data fields. On the estimate form is a command
>>>>>>button to
>>>>>>convert the estimate to a scheduled job. When the user clicks the
>>>>>>button I
>>>>>>would like to copy certain fields and paste them to corresponding
>>>>>>fields in
>>>>>>a projects table. Could someone point me in the right direction on
>>>>>>where to
>>>>>>start this process?
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>