Convert string to formula (1 Viewer)

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 19:08
Joined
Feb 28, 2001
Messages
27,138
My take on this is that he is adding a layer of complexity because of trying to translate a concept that is not native to Access. Dynamic formula evaluation (where the formulas aren't intrinsically defined at design time) means that either the problem is HIGHLY fluid and not entirely suited for a compiled or even semi-compiled environment, or the user is being given entirely too much late-defined control where there is unlikely to be an experienced developer to handle the result when the EVAL problem goes awry - and it WILL eventually go awry.

The correct way to handle this is to NOT handle it at this stage of the game. Go back to the problem's written description (or MAKE one) and decide what you really wanted to do. REDESIGN the solution using Access concepts and DITCH the Excel concepts, or else give up on Access and stay with Excel. While I know that some situations can get complex, deferring definition of the required formula does not improve the situation.
 

HiTechCoach

Well-known member
Local time
Yesterday, 19:08
Joined
Mar 6, 2006
Messages
4,357
My take on this is that he is adding a layer of complexity because of trying to translate a concept that is not native to Access. Dynamic formula evaluation (where the formulas aren't intrinsically defined at design time) means that either the problem is HIGHLY fluid and not entirely suited for a compiled or even semi-compiled environment, or the user is being given entirely too much late-defined control where there is unlikely to be an experienced developer to handle the result when the EVAL problem goes awry - and it WILL eventually go awry.

The correct way to handle this is to NOT handle it at this stage of the game. Go back to the problem's written description (or MAKE one) and decide what you really wanted to do. REDESIGN the solution using Access concepts and DITCH the Excel concepts, or else give up on Access and stay with Excel. While I know that some situations can get complex, deferring definition of the required formula does not improve the situation.

Excellent advice. Well said.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 19:08
Joined
Feb 28, 2001
Messages
27,138
Hardy...

Let's go back to first principles. You said

I need to evaluate a number of things with different formulas eg.

Field1 * Field2
Field3 + Field4
(Field5+Field1)/Field5 and so on

I'd like to store the formulas in a field and then run a query to evaluate the answer.

Make sense?

The initial answer SHOULD have been "NO" because you are hiding the problem with formulas. Say in English WHY you want to do this. What do the formulas represent? We can tell you how to re-invent wheels if necessary - but we would prefer to guide you into using more traditional wheels that don't need re-invention.

If I had to, I could even tell you how to build a dynamic compiler for immediate in-line expressions, except that EVAL() can do that without me telling you how to compile code. But EVAL is more of a last-ditch blow-out patch for cases that are not clearly capable of any other way of solving the problem. When you are using EVAL you are admitting that you cannot design your solution via prior analysis techniques.

If Access has any strength at all, it is that the environment allows you to design and build complex interfaces. The more you know ahead of time, the better off you are when building that interface. Of paramount importance, you must know what you need to do before you do it. We sometimes compare the process of problem analysis and solution design to a road map. In essence, we come to the philosophical question: If you don't know where you are going, how will you know you got there?

It is for this reason that we need to know IN ENGLISH what you are trying to accomplish. Enlighten us, please.
 

hardy1976

Still learning...
Local time
Yesterday, 17:08
Joined
Apr 27, 2006
Messages
200
All thank you for your advice, sorry for the lack of a response but I have had the lurgy and the last thing I wanted to do was look at my computer screen :)

The last last last last thing i want to do i reinvent the wheel or make something more complicated than it needs to be. I like keeping things simple.

In basic English this is the issue I'm trying to resolve.

  • I have a table full of orders with various details.
  • I have a list of rates inc minimum order and so on.
  • What I would like to do is calculate an invoice.

The calculation aspect is where I am struggling as it varies from order item to order item.
 

hardy1976

Still learning...
Local time
Yesterday, 17:08
Joined
Apr 27, 2006
Messages
200
The reason for this being in Access is so the data is all on once place and searchable/query-able.

Thanks
 

CJ_London

Super Moderator
Staff member
Local time
Today, 01:08
Joined
Feb 19, 2013
Messages
16,607
Calculating invoices is a very 'normal' thing for databases to do.

From what you have described so far, your calculations would just be done as a calculation on a query or in a form or report.

Suggest provide details of your relevant tables and their relationships plus some example data. If you use their real names, code can generally be provided which you can just copy and paste into your app.
 

hardy1976

Still learning...
Local time
Yesterday, 17:08
Joined
Apr 27, 2006
Messages
200
sneuberg post at 02-05-2017, 07:46 AM #18 sums up basically what I am trying to achieve - well it does it.

If this is not the right way - please point me in the right direction. I really dont want this to be complicated!
 

Attachments

  • APF.accdb
    508 KB · Views: 87
Last edited:

stopher

AWF VIP
Local time
Today, 01:08
Joined
Feb 1, 2006
Messages
2,396
My take on this is that he is adding a layer of complexity because of trying to translate a concept that is not native to Access. Dynamic formula evaluation (where the formulas aren't intrinsically defined at design time) means that either the problem is HIGHLY fluid and not entirely suited for a compiled or even semi-compiled environment, or the user is being given entirely too much late-defined control where there is unlikely to be an experienced developer to handle the result when the EVAL problem goes awry - and it WILL eventually go awry.

The correct way to handle this is to NOT handle it at this stage of the game. Go back to the problem's written description (or MAKE one) and decide what you really wanted to do. REDESIGN the solution using Access concepts and DITCH the Excel concepts, or else give up on Access and stay with Excel. While I know that some situations can get complex, deferring definition of the required formula does not improve the situation.
Why do you say the OP is using Excel thinking. As I see it the OP it describing a real world problem i.e. the calculation of charges are dependent upon a charge type (which presumably can be create/edited by the user). This pops up often in the real world e.g. taxes, VAT where the formula is different depending on the type. The idea that this cannot be solved in Access because it is not native is dismissing the problem imho.

Of course it would be easy to write a query for each calc type then just run them to update the respective costs. Or alternatively, hard code a formula to do much the same. But this approach does not easily allow for new calcs to be added by the user - not an unreasonable request given how often tax calcs change (at least in the UK).

Noting Doc Man's concern about the parsing problem and also sneuberg's offered solution, I wonder if the approach is it provide an interface where the user can build a formula via drop downs (giving the valid fields) much like the formula builder used in Excel Pivot tables. The formula is then used to create an Update query (since all the syntax has been already forceably defined) - no need to Eval. Any testing can be done at the time of definition - rather than it falling over at Eval time. Just thinking out loud..
 

sneuberg

AWF VIP
Local time
Yesterday, 17:08
Joined
Oct 17, 2014
Messages
3,506
I'm working on a solution that might work for you but I need to know a bit more about your business.

Goals - $30 / IIf((session.goals * goal)<$100,$100,$200)

Please tell us more about what kind of product or service a goal is.

Teacher - $50 / session.teachers * session.hours * teacher

Normally an invoice would have a rate and quantity but this scenario involves a rate and two quantities (hours and teachers). Is your invoice going to have two columns for quantity, one being normal empty, or could your break this down and create separate line items for each teacher?


In the database you posted your have the formula: [players] * [basicrate]. Could you tell us more about this product or service?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 19:08
Joined
Feb 28, 2001
Messages
27,138
stopher - perhaps "Excel thinking" is not a technically correct phrase, but it conveys (among other baggage) the idea of extremely late binding of formulas. Perhaps if I call it that, you would object less to the language.

hardy - it is my thought that you might benefit from a little more forum searching for key word "invoice" or "invoicing" because you would CERTAINLY see how other people have used Access to approach this problem. And now that we know this is an invoice builder, we CAN direct you to ways to do things.

I will also say that to bring this into Access, you will face one very tedious hurdle - the problem of initial definition of your data. I.e. inputting the things that CAN be invoiced along with whatever indicators you finally choose regarding rules, tax rates, discount rates, etc.

From the discussion and now knowing that this is an invoicing system, you need to define ON PAPER the following ideas:

- What do you sell and how do you sell it? This leads to an inventory table where each line item might have several codes related to the questions that follow.

- Rules on minimum purchases, potentially subdivided into total purchase and whether there is also a minimum for a given item. Total purchase minimums are usually implemented with VBA in the forms used to build the invoice, perhaps assisted by fields in the inventory line-item table showing a minimum purchase code which could be "minimum in context of total purchase, minimum in context of number of this item, minimum in context of currency value of purchase, etc."

- Rules on discounts, which could include various tiers that differ from product to product. Again, could be supported by another code field in the inventory line item table to indicate which of several possible discount schedules would apply. Also, if you have discounts for the elderly, disabled, veterans, or students...

- Rules on taxes. You are in London, and therefore I don't know your tax rules. However, in the USA, we would have to consider whether a particular item was fully taxed or subject to certain tax exemptions (like, no national-level taxes on baby food - or something like that). Again, the inventory line item table could hold a coded field for this case.

- Rules on shipping rates, such as cost tiers based on weight of the shipment or on the number of boxes required, as well as on distance to be shipped.

- Rules on order of application of the other rules. Like, if a discount occurs, do you discount the price pre-tax per item or is there a different rule that says "tax full price" but then apply discount to the cost, leaving the total taxes alone.

Once you have definitions for any rules that apply, you can start towards proper implementation. However, in Access, you ALWAYS benefit from a little extra analysis before implementation. The more you know, the easier it will be to encode your rules, whatever they are.

Hardy, I know this sounds daunting. But remember - it has been done before. Each company has their own in-house wrinkles on this problem - but it has been done and therefore must be eminently doable.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 01:08
Joined
Feb 19, 2013
Messages
16,607
using the example the OP has uploaded, and in line with Doc's comments about business rules

just adding a 'minimum charge' column to tblFees would resolve the problem. Put 15 in the Lighting record and 0 in the others.

In a query you would then have

Cost: IIf([unit rate] * [units]>[minCharge],[unit rate] * [units],[minCharge])

which will work for all invoiced items - if mincharge is 0 then it is effectively ignored.

You could add another column for max charge. And if charges are on a sliding scale you would need another table to identify breakpoints.
 

hardy1976

Still learning...
Local time
Yesterday, 17:08
Joined
Apr 27, 2006
Messages
200
The_Doc_Man - Thanks, I will do this and have a look at invoicing on here.

sneuberg - I was keeping the example simple, so I thought of an easy example. A football equipment hire place, you can hire pitches, goals, footballs etc.

Teacher - $50 / session.teachers * session.hours * teacher
This was basically, how many teachers/referees are you going to have multiplied by the length of the session (hours) by the rate for hire of a teacher/ref.

All of the formulas were examples, the key is trying to work out how I could apply varying equations.

Thanks
 

Minty

AWF VIP
Local time
Today, 01:08
Joined
Jul 26, 2013
Messages
10,366
Just my 2p worth - I think reading this again, that most of what is being asked for could be garnered from a BOM / assemblies style set up.

So for example, A football pitch hire would be made up of Referee x 1, Pitch x 1, Footballs x 3 , Goals x 2.

There are a lot of example data models of this type of set up.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 01:08
Joined
Feb 19, 2013
Messages
16,607
going back to your original example

Table1 - Rates / Calc
Football - $100 / session.footballs * football
Goals - $30 / IIf((session.goals * goal)<$100,$100,$200)
Teacher - $50 / session.teachers * session.hours * teacher

Table2 - Session
Session Number: 1
Footballs: 2
Goals: 0
Teachers: 1
Hours: 3

You could try something like

Code:
dim sqlstr as string
dim rst as dao.recordset
dim db as dao.database
 
set db=currentdb
set rst=db.openrecordset("SELECT * FROM Table1")
while not rst.eof
    sqlstr="UPDATE Table2 INNER JOIN Table1 ON Table2.item=Table1.item SET Cost=" & rst!calc & " WHERE Table2.Item=" & rst!item
    db.execute sqlstr
    rst.movenext
wend
 
set rst=nothing
set db=nothing

but this updates a value in table2 on a line by line (or item by item) basis within an invoice - you cannot have a query which uses different calculations for each row in the same column - unless you start using iif/choose/switch etc, but then you are back to the same, but more complex calculation.
 

Users who are viewing this thread

Top Bottom