Remember the whole dataset is like an Excel sheet, with 1 row per id, and the columns as different fields per id.
All those cells will be written and read to check against triggers (where the triggers are also fields in the table, or columns in Excel as you wish)
You said you want to store Bid, Ask and Open in a single record, but I argue that using three records is easier. I wonder if you have stronger arguments for your design than that you want.
If you insist, I would change the way how you work with them. First of all, I wouldn’t use parm* methods for this purpose, I suggest them in your old threads when we talked about a simple class holding the data. Now you have a table instead of the class that would have parm methods.
Interesting, let’s discuss this first.
Why is 3 separate records per _id easier than 1 record with different fields?
Actually in full implementation it would be then 28 records per _id instead of 1 record with 28 fields.
I designed it this way because I’m used to save data per _id. (Like custtable or inventtable [emoticon:c4563cd7d5574777a71c318021cbbcc8]
But I’m open for a better design, however I don’t grab it yet.
Pls explain
I think that I demonstrated that that my code handling all 28 cases it’s simpler than your parm method, which would have 27 extra copies. So it’s an order of magnitude simpler.
It would be possible to greatly simplify your code, but it would still be much more complicated, both from the perspective of the data model and the code. If there is no reason for such complexity, introducing it can be consider a bug in design.
If “I’m used to save data per _id” means that you’re not familiar of primary keys consisting of more than one field, you’ve just learn something new. 
You should add relation database design to things to study.
Nw when I read your code I understand. That is, what’s coming in from oneventTickPrice.
There are only 3 values from that method.
The other fields, like spread, status, price 5 min ago, price 10 min ago, triggerprice, stopprice etc etc just to name a few, which are all calculated by me, has to be written too.
Should that mean that everywhere I want to write an own calculated value, I have to call select forupdate temptable etc?
But also everywhere I want to read a value, I have to write a select statement?
That would make the code harder to read, that’s why I have put it in the “parmMethods” (however I understand that that code was not designed for tables…)
But I mean in my method PriceCalculation:
tmpTable.Spread(_id, tmpTable.ask(_id) - tmpTable.bid(_id))
Is easier to read than doing this with 3 selects in the code?
So thats why I put those methods “on a higher level”
Besides that all the other 25 selfcalculated fields has only to do with 1 id and independent of the tickType.
And specially that I don’t understand why I would spread it over more records per _id.
I did mean that per id a record is hold, like custtable etc. I know primary keys of n fields.
Now the above looks like I think I know it better than you Martin. Well…for sure that’s not the case. Compared to you I’m a starter [emoticon:c4563cd7d5574777a71c318021cbbcc8]
For sure it’s good to code as clean as possible to avoid bugs etc, but it looks like we have a different view of the tabledesign in this case.
Wait…now I’m cracking my head around it:
Is it that you think of more tables?
1 with “basic data” and a lot of (myself calculated) fields , and 1 joined with this maintable, where you put the price records per _id and _ticktype as in your example?
I’m not aware of you saying that all other values are calculated, therefore I couldn’t take it into account. I work with the information I’ve got; maybe you now understand why I asked for more information from you. It would help if you started by explaining what you’re doing, instead of immediately jumping to implementation details.
All right, so you’ll have fields like Bid and Ask populated by yourself. But your implementation of parmBid() and parmAsk() suggests that you intend to select and update the record for every field individually, which looks like a waste of resources to me (as I mentioned before). It also keeps the data in inconsistent state, before the last field it updated.
I would expect logic like this (it’s a demonstration, not necessarily how I would write it):
void onEvent_TickPrice(int _id, int _tickType, real _price)
{
select forUpdate tmpTable
where tmpTable.Id == _id;
tmpTable.Ask = ...
tmpTable.Bid = ...
tmpTable.Spread = tmpTable.Ask - tmpTable.Bid; // No three select statements, as you claimed
if (tmpTable.RecId)
{
tmpTable.update();
}
else
{
tmpTable.Id = _id;
tmpTable.insert();
}
}
Then you said that “everywhere I want to read a value, I have to write a select statement” and suggested that your parm methods are the only solution. That’s not true. Look how it’s usually done in AX:
myTable = MyTable::find("Id1");
info(myTable.Field1);
info(myTable.Field2);
As you see, it doesn’t require writing any select statement (although one is hidden in find()) and it doesn’t require a select statement for every field, like your parm methods. Because it’s easier to write and read, it’s less code to debug and maintain and it executes faster, it looks like a better solution to me.
Just note that if you want to write a method like find() for a temporary table, you must select data from the buffer where they’ve been inserted. If you create a new, empty buffer, you’ll never find any record. For example, you can pass the buffer as a parameter:
public static MyTmpTable find(str _id, MyTmpTable _buffer, boolean _forUpdate = false)
{
...
select firstOnly _buffer
where _buffer.Id == _id;
...
}
Finally I’m glad we’re looking at the same page now. I thought I was going mad…
Altough I’ve mentioned that I had more (calculated) fields, appearantly not clear enough.
It’s difficult to know what the other side doesn’t see if the concept is obvious in my head.
So next time. I will first explain concept totally before going further.
Now the above solution is clear as water. That’s the approach as it should be and I have to admit that I drifted away a bit too much in the parmMethod solution, hereby forgetting the normal tablemethods.
So code here will be reflected and rewritten, which is an easy task with your samples.
As last, but not least: Thank you for your incredible patience and helping hand.
It was a “long road” but on that road I learned many things!
Have a nice evening!