All Activity

Hi Mike, It seems that your sample file does not work with FM17. Can you please have a look ? Thank you

No, I don't think so. Operations will often (if not always) force casting into the type expected by the operation, regardless of the originating field's type.

That's right, but operations on the data in a field very often will force casting into underlying field's data type. Which is why it is often important to know the field's data type so that you know what it is supposed to be.

I hate to continue this, but: Field type is not data type. As you yourself said, Filemaker permits inputting the wrong data type into fields.

If it is a field: by querying the FileMaker_Fields metatable with executeSql(), or by using the FieldType() design function. If it is a variable: you can't. Much like other environments where you declare a variable 'untyped' by doing something like 'var myVariable', FM works the same. Except that you don't have a TypeOf() equivalent. As a developer you need to know what you put in the variable. When in doubt just use the right GetAs...() function.

With a plugin. Please stop hijacking this thread.

Interesting, how can I retrieve the data type from the object?

Hmm, you're the second person to tell me the same thing in the last 12 hours. So it must be some magic touch that I have ...😉

When you say we can use a global field , I have tried this in the past and not been successful. I will try again if you think it should work. Yes this just runs on my desktop, it is not hosted. Hey, that works! Huzzah! Funny that it has not worked for me in the past, I can't think of what I was doing differently. Many thanks for your assistance.

Then perhaps you could simply change the timestamp field in the related table to a global field, auto-entering creation timestamp. Then the field will update for all records anytime you create or import a new record. It should be stressed again that this will work only for as long as the solution is not hosted.

Maybe I'm not describing it correctly. The import always has records because it contains all of our eBay listings, usually 3500. But eBay ends listings from time to time, so when we look at the record for a sku where the listing was ended, the timestamp doesn't show up, but we want it to. Regarding scripting, I've just never developed the skill with scripts so always try to avoid them. We don't have to manually update the timestamp because we delete all the records and import the latest download from eBay, so the table always gets fresh records and a new creation timestamp.

That has nothing to do with data types, what that speaks to is that FM is permissive in that it does not prohibit the user from inputting the wrong data type into fields, it leaves it up to developer to put validation rules in place. FM does NOT treat everything as text as you claimed. Even a variable will maintain the correct data type of what you set into it, including container data.

If you do not script any part of this process, then you will need to update the timestamp field manually too. Because - as you have found out - if the process ends up with no records being imported into the related table, you have nothing that would hold the timestamp of the import attempt. I don't see why you wouldn't script this, at least in part. Then you can use a global field, in any table.

Yes all related records have the same timestamp. The related table is update for all products in one import. I don't use a script to update the tables, I just manually download them (this is a one-user system).

First you write an example that is non-declarative and then you make a statement that makes no sense to me. Can I no longer import letters into Filemaker's number field? I just tried `S10000` is still valid number field content. Do you know what data types are?

Complicated in the sense that: not test will do exactly the same thing in fewer evaluations, less code and much more readable way. And since I already said this is irrelevant to topic of this thread, I will end this discussion here. Except one more note: You could not be more wrong.

Complicated how? Choosing a more declarative* apporach is a choice to avoid complicated usually. First you make sure the datatype using `GetAsBoolean()` then you delegate the outcome using `Choose()`; in which is FileMaker's equivalent of `switch`/`case` statement in other languages? For all practical reasons but `default:`. I'm not sure where you are able to complicate this? At least this is what I have to do in `c`/`cpp`/`swift` to avoid making assumptions. In FileMaker everything is text regardless and certain safety measures will have to be put in place. * In computer science, declara

If all related records have the same timestamp, then there is no point of having the timestamp field in that table. Place it in the parent Products table and make the script that updates the related table update this field too. This is assuming you update the related table for each product separately. Otherwise, there is no point in having the same timestamp replicated in all the product records. Place it in a single-record Preferences table instead.

I have a main table of products with skus, and a related table (matched on sku) of data from eBay with listing information about the sku. When I update the related table I show all records and delete them, then re-import with the latest download from eBay. That all works fine. I added a timestamp to the related table so I'd know how recent the last download was. In the main table I display some data from the related table, such as price, and I have a field next to it showing the timestamp from the related table. My problem is that if the related table has no data for that particular sku,

I don't think anyone can answer this without performing a test. Note that you have several options here: place the files in container fields, using either internal or external storage, or keep your existing method of storing only the filename in the database and accessing the files on 'as needed' basis. Each has its pros and cons, and can have different results in terms of performance. You can calculate the filepath on the user machine if you know where the user put the folder. If you can make sure that all users place their mp3 folder in their Documents folder (or in a known folde

I have found that opening url to an mp3 file will play much faster then playing the audio from the container field. Also i believe the record is opened (locked) while the audio is playing/streaming.

Hi @Wim Decorte, thanks for your reply. I have a field on my layout that is set up as a container field with: the "Security container data externally" checked "relative to [hosted location]/Files/Db Name/" "Security storage" is also checked I then have a script that: Goes to audio field Sets variable to calculate $filepath using the track title (filepath is a on a mounted cloud drive that shows up in finder so all filepaths are the same for all users who connect to that drive. That cloud drive is mounted using a separate standalone app called Expandrive.) I

The two screenshots were made in the same window. Anyway, the problem seems to be fixed now.

Yes, that conforms to the trend of "why make it simple, when it can be complicated" - which is so popular in the Filemaker community...

Ah, you're a much more careful reader than I am, @comment. Didn't catch the possible need for a sub-summary.