need help with field

[michael siahaan]

Hi,

 

If I have 100 fields ( field1,field2...field100) each of them containing number. Are there any way to make calculation field refer to that field but it dynamically shift to the next field? for example:

 

field A = sum of field 1 to 5

field B = sum of field 2 to 6

field C = sum of field 3 to 7

... and so on

 

Please advise

 

Thanks

[Maarten Witberg]

well,

 

fieldA = sum (field1 ; field2 ; field3)

or

fieldA = field1 + field2 + field3

fieldB = field2 + field3 + field4

etc.

 

but I have strong suspicions there is something not right with your database.

What are you trying to build?

[AHunter3]

I think I followed the original question, although I totally agree with kjoe & have grave misgivings about your structure based on the little you've told us.

 

If your fields are genuinely & truly named with a naming convention such as field1, field2, field3, you could use GetField() in conjunction with a global field to snag the specific range of fields you want, e.g.,

 

GetField ("field"&g.SuffixGlobalNumField) + GetField ("field"&g.SuffixGlobalNumField+1) + GetField ("field" & g.SuffixGlobalNumField + 2)

 

should reconcile to field1 + field2 + field3 when g.SuffixGlobalNumField contains 1;

 

should reconcile to field2 + field3 + field4 when g.SuffixGlobalNumField contains 2, and so on.

[michael siahaan]

thanks kjoe,

 

but if in that way i have to type hundred of calculations of field A B C and so on and it gonna be complicated since this is not the only calculation in there; is there anyway like:

 

field A = "Sum" field 1 to 5 -- easier than types sum field1+field2+field3+field4+field5

 

I'm building an inventory estimation database for 52 weeks. It contains fields like current stock, estimation , average day supply, number that must be order, etc

[Maarten Witberg]

true but why do something like that when you're storlng the results in separate fields also?

 

edit: this is in reply to Allan's post

 

 

[Maarten Witberg]

Michael, you need to reconsider your structure. I'd say something like one week, one record. if you have multiple inventory items it's going to be different still. you need to tell more if you need more help. the only thing I can say is the one record = one 52 week estimate is not good. Making an estimate may actually be more of a spreadsheet job than a database job, although databases can be made well suited for this I think, but not by making them look like a spreadsheet which is what it looks like from what you told us.

 

EDITED (too)

[michael siahaan]

Hi guys,

 

so what am i doing right now is something like this:

 

I have 52 weeks database to count stock,actual sales, sales estimation trend, etc, and I set 52 fields for each of them

 

Say to count sales estimation on week 10, I need calculation using actual sales from week 2 to 8, then to count estimation on week 11, I need calculation using actual sales from week 3 to 9 and so on.

If there's a way like excel say sum(field1:field10) would be easier for me to set the calculation better than sum (field1;field2..field10)

 

I'm thinking about getfield too but pretty confused with it.

 

Thanks

[AHunter3]

true but why do something like that when you're storlng the results in separate fields also?

 

edit: this is in reply to Allan's post

 

 

I dunno, I can't figure out what the OP is really trying to do.

[Maarten Witberg]

sorry Michael, but again: if you want to build a spreadsheet, use excel...

[michael siahaan]

Thanks kjoe,

you're right.. i did this usually at spreadsheet on excel, just wondering if i can integrate this with filemaker.

[Maarten Witberg]

you can, but you need to rethink this as a database. This means

- making use of the relational possibilities

- thinking about the smallest unit of information in your stock database which I'm guessing is one amount of one product in one week and work from there.