Global fields are a unique FM contraption and there is no equivalent in MySQL.
When you define fields in FM on the remote table you don't really create fields in MySQL but you are creating 'shadow' fields that only exist in FM. But you can only create those two calc and summary field types.
Yes FM is aware of this issue as it is not a defect but is designed that way.
if you want to create field in MYSQL go to MYSQL
SInce we cannot add global fields into remote table; is there any other ways or an alternatives solution available which would allow us to have an 'shadow' fields in remote table and than allowing user to use them to do some filtering.
As far I know global field were really good to allow user to input some text then script running to do filter in portal.
I dont think ExecuteSQL would be good to filter on actual field. Because if i have an actual field; whatever user will type in will get saved in database. So i don't think that can work..
So what would be an best alternative way to have a field on top of portal; user type something in and script run to filter the portal.
Thanks in Advance.
Why not put the global field in a local FileMaker table instead of the SQL table?
I can do that. But the actual data of application will be coming from the remote tables (MYSQL). The layout will be based on a remote table. How I can use another table to store global fields than link it with remote table.
1 of 1 people found this helpful
Well it's a GLOBAL field. A global field can be referenced from any layout in your file. That's one of the main reasons for using a global field in the first place.
Thus you can define it in a FileMaker file table and still refer to it in a portal filter expression. you can also base a layout on the local Filemaker file table with the global field and use it as a match field in a relationship to the remotely sourced table in order to place a portal on that layout.
a "probable" equivelant might be the Constant/Literal that you can supply in a SQL query. But unless those are being made by script, unlikely a good usage here and certainly a lot harder without a global field to store the value that would be used in a query from FM to MySQL.