Will the database be able to conduct these functions in order, or might the database compare the corresponding csv and db fields, before the fields have a chance to update from the calculation already set up in the db?
The order will depend on the script. FM will not be able to perform anything on the csv file until it is imported. I suggest importing the csv file into a csv import table and then have your script to update the main database from this import table.
Like I said, I am not a developer. But yes, my developer has a csv import table. So you are saying that the import has 2 steps? (1) import all data into csv import table, then (2) update info, move info, whatever (exactly what happens here is foggy) into my main database?
Curious as to why you aren't asking your developer. They are in a position to answer the question far more effectively as they should know the exact requirements of the project and the data used to achieve it.
We on the other hand have to guess quite a bit about what you want to do here and that limits the effectiveness of our answers.
Import does not require two steps. In your scenario, I would use two steps, I import into a temp table then run a script to do the computation then update the main table.
If you have your own priest, why ask questions in the church ?
Filemaker can do everything you ask it to, you just need to ask the correct question.
Which in your case is not deligned precisely: your original post title hints to performance, while the content is as misty as it can get
Echo PMJ and siplus..
If you don't trust "your developer" to answer these questions you hired the wrong developer.
First to answer your questions about the priest, I don't rely on the answers of one priest, nor do I rely on the answers of one doctor, nor one teacher. Which is why I might read a passage from the Bible myself, go for a second medical opinion, or get extra help from a different teacher. I suspected this question required knowledge that not every developer has, so asking a large group in hopes that someone might understand and have some valuable info to offer (gotten from their unique experiences) was my hope. It's a great venue to get info. But this is not the focus of my post, so lets not get caught up here. And yes, of course I will ask my developer as well.
Second, I believe that the info I gave you is all the info you need to answer the question. I could be wrong being so close to it that I am inserting info you don't have and I don't realize it, but it seems as if you have all pertinent info. And I don't want to write a book explaining everything since it would more likely confuse rather than clarify. I also would have to be a very good writer to explain it clearly, which, evidently I am not.
Regarding the hint about performance, yes, the entire question is about performance - speed. I don't see the mist, but OK, if you were confused, I will take the blame.
But I think I may have figured out the answer. I think the answer is NO, this probably will not work. And the reason is because 2 calculations are happening simultaneously, it's not one calculation happening linearly. So there is a race going on and chances are, at least sometimes, the calculation I want to finish first, won't finish first. So the set up is not reliable. If I disable the database's internal age/grade calculation and add it to the one script at the right point, we then are dealing with one, slightly longer script, and (still not 100% in my mind yet but) I think it can work that way.
Then you haven't provided enough information. A bit too much "hand waving" as I don't see anything that would require that two calculations take place at the same time.
1) You might enable auto-enter calculations for an age field with an auto-enter calculation or 2) define a calculation field in the target table into which you import this data to compute ages as the data is imported. This newly computed age could then be compared to another field that imports the age as a value from the CSV file.
Database compares the corresponding csv age and grade fields to the (possibly) newly updated db fields If there are any changes, take some action - not important.
Is pretty "misty". I can think of any number of tasks that fit that description and I wouldn't implement them all the same way.
Second, I believe that the info I gave you is all the info you need to answer the question.
This is what you believe, but I'm a 54 year old fart which might need a bit more info than you believe.
And your cited sentence makes me uncomfortable, like being blown smoke in my eyes in an interrogatory room with seats soldered to the floor.
First, thank you Philmodjunk for your responses. I appreciate your helpful feedback. BTW: I misspoke. One calculation is being performed at the same time that a script is being performed. (The grade calculation is triggered midstream of the import script.) So I think your idea to define calculations in the target table can be a solution as well.
Second, siplus, I do not know what you are experiencing but I don't think it's coming from me.
Thanks for all help!
One calculation is being performed at the same time that a script is being performed.
What do you mean by that? This is not really possible.
Sounds like auto enter calc fields on import might work just fine, but hard to say for sure without seeing the calculations.
1 of 1 people found this helpful
This is super fast and you can control the evaluation dependency so some things need to calculate before others.