I did not export tab-delimited since 1994 but it still is default in FM - shouldn't this at least be its own format? ...and I will not start on setting preferences
Iโm using tab delimited export to move data from one system to another all the time.
It would be nice to have a built in JSON export option.
tab tab return is the most efficient one and the easyest
but yes for json option although data APi mais do the trick
Manage... Database Tables tab: I've long wished for a Comments field beneath the table name field at the bottom (similar to Fields tab).
With the Fields comments we can interact with them via scripts/calculations, but I'm not even asking for that. Sure, it might be nice, but just a simple comments/notes field to describe the purpose of the table would help in moderately complex solutions. Yes, I use semantic names for tables, fields, and variables, etc., but in solutions with 100+ tables (or much more) it can be difficult to recall how/why a table is used; especially if one is not working in the particular solution constantly.
In my use-cases this is not desired for tables such as "Invoices", "InvLineItems", etc., but for tables used for certain system functions, utilities, behind-the-scenes worker stuff.
Having the ability to organize Custom Functions into folders, similar to how we do for scripts and layouts would help me better organize them. I don't think that I would need an arbitrarily large depth of nesting of folders -- just one or two levels deep, so that I can more easily hone in on families of functions that are related to one another.
I would like to be able to select a Custom Function in the list and the Custom Functions used within this Custom Function are then highlighted.
At present I describe the purpose of the table in the comment field of the primary key but I'd prefer to find that comment in the Tables tab
I do the same, Malcolm. I've just wanted the input similar to fields for a long time. It seems such a simple request.
For layouts I use somewhat verbose (descriptive) names as necessary (e.g. "Add or Edit Client Contact | Card", but wouldn't mind a notes field there as well. It has also struck me as odd that the Layout Manager doesn't have a column showing layout number, since script steps like "go to layout... by number or name" can utilize them. Easy to extract if wanted, but just seemed odd to me.
I have a 'documentation' unstored calc in each table in which I describe the table purpose (and also some JSON structrued metadata if I need to)
great idea @FabriceN ! I use void custom functions which describe via Get (LayoutTableName ) the purpose and can be called then from a tooltip or some service layouts ..
Hi @mrwatson-de
Below is a good starting point that I have been using internally.
Please note that there are some edge cases if the data has unusual combinations of special characters.
And yes, would be good if it was built in.
View Menu > Show; a check box to show all or hide all on top of the itemized options (Selecting each of them one by one drives me nuts)
@mipiano With at least one monospace; I use monospace for various things, among which timestamps; it allows me to split and wrap it in the ui.
Also... being able to widen the window in the inspector especially for styles or import dialog to see the fields names (you-know-the-TO-name-is-long::soIcantSeeTheFieldName).
I was told that they could do it in Mac but not in Windows because of legacy systems. I think that most developers are on Mac anyway so since we are the ones who most need this... they should do it as a Mac only feature.
I do a lot of data maintenance for client. Often time, it is impossible to create the foundset from finds. I am provided with lists of ids.
Would be great if the ability to just create a foundset by import existed. The update already has the functionality but you are forced to have at least one field to import.
I create a field by default in all my tables: zzz_foundsetLoader. So that i can create a foundset from an id list that I import as an Excel file by using Update, Match on the id, import the zzz_foundsetLoader; don't perform auto-updates.
Have you thought of making a snapshot file from the IDs?
How do you make a snapshot file from an Excel file?
Snapshot files are text (xml). Create one and have a look. Itโs very simple. The IDs used are the same as you get from Get(RecordID).
You can actually load the list of IDs in a global field, create a self joint (global to Id) and GTRR.
Left is the export of the record ids, Right is the snapshot; left has 69 records. I don't understand what right side shows. Get (recordID) are native IDs. User don't see them so they can't provide them. If I have to upload the list of known records identifiers to get the native ids, it defeats the purpose!
Still need to have a dedicated field even if in a utility file and I'm too lazy for the self join and gtrr utility script. Those are workarounds. Native functionality would be better.
I understand but then the feature you need is different, itโ dynamic GTRR.
And that is much more multi-purpose