obiobson

I was thrilled to follow your discussion and see where a simple relation related question can take you guys! No blame for hijacking, though! So cutting a long story short, you strongly suggest to not rely on a calculated value in the relation, especially in regard of speed issues, but recommend to have a script set (and un-set) a flag and build the relation on that. So, I think I will go for that and say goodbye to my "floating" calculated system. In the end, it is very true what Ugo said: In the real world, things might easily not add up as maths would have expect you, and you might

Hey guys, thanks already for your fast and valuable input. Perhaps I might add that the system is working in the context of a theatre agency. So there is a bit of a different logic behind it, not being so much an "online-shop" thing. Like this, it was my intention that the user just types in the amount of the transfer and then chooses an invoice which is related to that payment. Once this link is established, all relevant data is hooked up with this payment, i. e. who sent the money, what theatre play this relates to and which author gets the royalties. What I do not so much like about

Hey everybody, I did my best to find a solution to my problem in the existing threads, and spent hours while searching. So I hope I was not just too blind to find anything ... I am in the process of building an FM database which is basically dealing with all relevant tasks of a small business. Like this, you can put together invoices and you can register payments and link them to the respective invoices. The invoices and payments tables are linked by a join table, which not only contains invoice-ID and payment-ID but also a specified amount, so that one payment can be linked to sever