calc field help.

Can somebody help me?

thanks for your support.

Ann

DATA.zip

Hi Ann,

As I understand it, the logic part of the Sep mod is kept in a third file that has one record for each record in the data file, linked by unique ID. These records contain no data aside from the ID, but all the calculation fields referencing information on their related data fields. This means that you have to duplicate some of your relational graph in the Logic file. On a layout, fields from the data file and the logic file would be displayed and would appear to the user to be part of the same record.

Unfortunately, while theoretically cool, this model still seems quite clumsy to implement and you lose a lot of the convenience that FM offers. For example, to do what you want in your file, you would need to make sure that a duplicate Logic record with an identical ID was created every-time a new computer, software or join record was created, then you would need to create a TO's for the logic tables and plug them in to appropriate parts of your graph, and then you would need to create a calc field count(software::ID), and finally you would need to carefully consider your TO graph to see what refreshing issues your calcs might have.

Kind of a hassle, no? This is also why I have not responded to the other post of yours asking for a simple template of the data/gui/logic sep mod; I am looking for one myself. Why do you feel you need to structure your database this way? Have you considered just splitting the interface out and keeping the data and calcs in the same file? I believe this is the most common way the SepMod is put to use. It is easy to do, and offers plenty of advantages on its own.

So, to answer your specific question of "Can I do this without a relationship in the data file?" Possibly, but not easily. The reason why yours does not work is that there is no relations in the graph in the file with the calc, so there is no related data to work with.

-Raz

thank you Martha and Raz.

I don't speak very well English.

I need one day's time.

If you want, you can adjust my files.

Ann

ok, Raz.

Is this the way right?

Ann

DATA_rev1.zip

Well thats ok, my french is terrible. I wish I had a simple and short answer for you, but I am afraid you may have to get someone to translate...

OK,

I see what you are getting at now. Is it the right way? Well, I am not sure what your ultimate goal is, but the calc returns the correct value, and I can't see any refreshing problems used in the current context.

This is a different method for splitting the logic out of the data than I described above. Storing the logic as the actual text of a calculation in global fields, and then called by evaluate(gCalcText). I have experimented with something quite similiar to this method, but found that it drained my cpu dramatically once more than a few calcs were used, or if the calc was too complex. Also, you cannot specify trigger fields with this method. In addition, you are limited to the pre-existing relationships in the data file unless you manually update the data file as well(which defeats the purpose of the exercise in the first place).

Hope that helps. It can be fun to experiment with this, and I am sure the technique can come in handy in certain scenarios. But, do make sure you test this with several calcs and lots of records before comitting yourself to this structure...

Hi Raz

ok, I don't use evaluate(gcalctext) and I use count(computer::ID).

Is this the method for splitting the logic out of the data?

but so we are splitting out of the data only user layouts and only interface scripts.

Ann

Hi Ann,

This is a method for splitting logic out from the data, but not a good one in my opinion.

Yes, I suggest you only split the layouts and scripts (you can actually run almost all scripts from the UI) from the data.

Good luck!

-Raz

thanks Raz

Ann