I'm creating a largish database that contains pointers to music files
(.aif) in containers. The database has reached over 1000 records in the
that use the containers. I've just noticed that over 500 of them now
display the message "The file cannot be found". I got this message once
before when I changed the name of the disc the files are located on.
(They're all on the same disk.) I managed to fix it then, but I don't
remember how. In any case, there have been no new disk name changes.

Any ideas? In previous posts, the feeling was that containers are a
mess.

Charlie
--
Nobody in this country got rich on his own. You built a factory--good.
But you moved your goods on roads we all paid for. You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward. Elizabeth Warren (paraphrased)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2018-04-03 00:41:48 +0000, Charles H. Sampson said:

I'm creating a largish database that contains pointers to music files
(.aif) in containers. The database has reached over 1000 records in the
that use the containers. I've just noticed that over 500 of them now
display the message "The file cannot be found". I got this message once before when I changed the name of the disc the files are located on.
(They're all on the same disk.) I managed to fix it then, but I don't remember how. In any case, there have been no new disk name changes.

Any ideas? In previous posts, the feeling was that containers are a
mess.

Charlie

Disk name changes, folder name changes, filename changes, files being
moved or deleted, an external drive not being mounted, copying files
from one user account to another, failing drive, etc. ... there are
MANY MANY possible causes for a "file not found" error.

If it's not as simple as plugging an external drive back in and
re-opening the database, then the only potential way to fix it, if it's possible to set the stored filepath (I vaguely remember reading about extracting the filepath from a Container field's link), MIGHT be to use
a Script and/or the Replace command with Calculation to fix the stored
links with the correct name, assuming you know what the correction has
to be and it is the same fix across all (or at least groups of) linked
files.

Otherwise, you would have to go back and re-insert all the files individually.

Helpful Harry :o)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 3-4-2018 om 03:36 schreef Helpful Harry:

On 2018-04-03 00:41:48 +0000, Charles H. Sampson said:

I'm creating a largish database that contains pointers to music files
(.aif) in containers. The database has reached over 1000 records in the
that use the containers. I've just noticed that over 500 of them now
display the message "The file cannot be found". I got this message once
before when I changed the name of the disc the files are located on.
(They're all on the same disk.) I managed to fix it then, but I don't
remember how. In any case, there have been no new disk name changes.

Any ideas? In previous posts, the feeling was that containers are a
mess.

Charlie

Disk name changes, folder name changes, filename changes, files being
moved or deleted, an external drive not being mounted, copying files
from one user account to another, failing drive, etc. ... there are MANY
MANY possible causes for a "file not found" error.

If it's not as simple as plugging an external drive back in and
re-opening the database, then the only potential way to fix it, if it's possible to set the stored filepath (I vaguely remember reading about extracting the filepath from a Container field's link), MIGHT be to use
a Script and/or the Replace command with Calculation to fix the stored
links with the correct name, assuming you know what the correction has
to be and it is the same fix across all (or at least groups of) linked
files.

Otherwise, you would have to go back and re-insert all the files individually.

Helpful Harry  :o)

My feeling is, that although filemaker does offer the container, it was
never properly meant to store files as if it was a library. Certainly I
had trouble when changing disks containing the source files. Which
problems cleared up when I then moved the files to a permanent location
and re-inserted them. I then rethought my solution and now only have
fields containing the complete path to a file. The field itself acts
like a button, launching a script, opening (or playing) the file. Which
in itself isn't a guarantee against broken paths, but does more easily
allow swapping disks.

for music collections there are enough free options to consider. Itunes, Mediamonkey, foobar2000.

--
Vriendelijke groet, Erik Appeldoorn

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Charles H. Sampson <csampson@inetworld.net> wrote:

I'm creating a largish database that contains pointers to music files
(.aif) in containers. The database has reached over 1000 records in the
that use the containers. I've just noticed that over 500 of them now
display the message "The file cannot be found". I got this message once before when I changed the name of the disc the files are located on.
(They're all on the same disk.) I managed to fix it then, but I don't remember how. In any case, there have been no new disk name changes.

Any ideas? In previous posts, the feeling was that containers are a
mess.

I've been working on this problem for a while and I've discovered a lot.
My big conclusion is that containers are such a mess as to be unusable,
so I'm giving up on this database and reverting to an organization of
audio files that I control.

Now, some details. First and foremost, my problems were caused by
changing the name of the disk (partition) that the files were on. Of
course, I had put only a reference to the files into the containers. I interpret this as using an alias; OS X's alias has long been able to
negotiate name changes, so the problem is basically that FileMaker is
not using the full capabilities of OS X. (Worse, in my estimation, is
that I'm not allowed to put an honest-to-God alias into the container,
but that's another issue.)

In trying to solve my problem, I came across the script function GetContainerAttribute. That function doesn't work, another poor
implementation of containers. The problem is with the second parameter,
which specifies the attribute being queried. I was interested in the
filename attribute. When I tried making that second parameter literally "filename", I got a "table not located" error message. I put "filename"
in quotes, which got around the error message but gave no information at
all, much less information about the file name.

I went to the FileMaker community and discovered that GetAsText works
for containers, returning the full path name of the referenced file.
(But see later.) Using this, I could see what was wrong and I wrote a
script to fix the problem -- up to a point. After around 550 containers, GetAsText suddenly started producing file names that weren't full names
and my script didn't work. I actually handled the file name problem
manually for the remaining 50 or so files.

However, I concluded that this fragility didn't bode well for my
database and I've abandoned it.

Charlie
--
Nobody in this country got rich on his own. You built a factory--good.
But you moved your goods on roads we all paid for. You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward. Elizabeth Warren (paraphrased)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2018-04-09 16:23:16 +0000, Charles H. Sampson said:

Charles H. Sampson <csampson@inetworld.net> wrote:

I'm creating a largish database that contains pointers to music files
(.aif) in containers. The database has reached over 1000 records in the
that use the containers. I've just noticed that over 500 of them now
display the message "The file cannot be found". I got this message once
before when I changed the name of the disc the files are located on.
(They're all on the same disk.) I managed to fix it then, but I don't
remember how. In any case, there have been no new disk name changes.

Any ideas? In previous posts, the feeling was that containers are a
mess.

I've been working on this problem for a while and I've discovered a lot.
My big conclusion is that containers are such a mess as to be unusable,
so I'm giving up on this database and reverting to an organization of
audio files that I control.

Now, some details. First and foremost, my problems were caused by
changing the name of the disk (partition) that the files were on. Of
course, I had put only a reference to the files into the containers.

The field store the filepath, so that includes the drive / volume name. Changing the drive's name means FileMaker can no longer find a drive by
that name.

I interpret this as using an alias; OS X's alias has long been able to negotiate name changes, so the problem is basically that FileMaker is
not using the full capabilities of OS X. (Worse, in my estimation, is
that I'm not allowed to put an honest-to-God alias into the container,
but that's another issue.)

In trying to solve my problem, I came across the script function GetContainerAttribute. That function doesn't work, another poor implementation of containers. The problem is with the second parameter,
which specifies the attribute being queried. I was interested in the
filename attribute. When I tried making that second parameter literally "filename", I got a "table not located" error message. I put "filename"
in quotes, which got around the error message but gave no information at
all, much less information about the file name.

I went to the FileMaker community and discovered that GetAsText works
for containers, returning the full path name of the referenced file.
(But see later.) Using this, I could see what was wrong and I wrote a
script to fix the problem -- up to a point. After around 550 containers, GetAsText suddenly started producing file names that weren't full names
and my script didn't work. I actually handled the file name problem
manually for the remaining 50 or so files.

However, I concluded that this fragility didn't bode well for my
database and I've abandoned it.

Despite the product name "FileMaker Pro", it is not actually designed
to catalogue actual computer files. It's simply a database for dealing
with textual and numerical data.

Container fields are only really meant to contain small files for use
within the database itself. Even then, the sound capabilities are
woeful, so Container fields are really only of use for graphics -
things like separate images for the two states of a custom button ("on"
and "off")..

Helpful Harry :o)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:

On 2018-04-09 16:23:16 +0000, Charles H. Sampson said:

Charles H. Sampson <csampson@inetworld.net> wrote:

I'm creating a largish database that contains pointers to music files
(.aif) in containers. The database has reached over 1000 records in the
that use the containers. I've just noticed that over 500 of them now
display the message "The file cannot be found". I got this message once
before when I changed the name of the disc the files are located on.
(They're all on the same disk.) I managed to fix it then, but I don't
remember how. In any case, there have been no new disk name changes.

Any ideas? In previous posts, the feeling was that containers are a
mess.

I've been working on this problem for a while and I've discovered a lot.
My big conclusion is that containers are such a mess as to be unusable,
so I'm giving up on this database and reverting to an organization of
audio files that I control.

Now, some details. First and foremost, my problems were caused by
changing the name of the disk (partition) that the files were on. Of course, I had put only a reference to the files into the containers.

The field store the filepath, so that includes the drive / volume name. Changing the drive's name means FileMaker can no longer find a drive by
that name.

Sort of. And that's why my script worked up to a point. But suddenly,
the "filepath" returned by GetAsText didn't return the full filepath.
What it did return was so minimally usable that I abandoned my script.

I interpret this as using an alias; OS X's alias has long been able to negotiate name changes, so the problem is basically that FileMaker is
not using the full capabilities of OS X. (Worse, in my estimation, is
that I'm not allowed to put an honest-to-God alias into the container,
but that's another issue.)

In trying to solve my problem, I came across the script function GetContainerAttribute. That function doesn't work, another poor implementation of containers. The problem is with the second parameter, which specifies the attribute being queried. I was interested in the filename attribute. When I tried making that second parameter literally "filename", I got a "table not located" error message. I put "filename"
in quotes, which got around the error message but gave no information at all, much less information about the file name.

I went to the FileMaker community and discovered that GetAsText works
for containers, returning the full path name of the referenced file.
(But see later.) Using this, I could see what was wrong and I wrote a script to fix the problem -- up to a point. After around 550 containers, GetAsText suddenly started producing file names that weren't full names
and my script didn't work. I actually handled the file name problem manually for the remaining 50 or so files.

However, I concluded that this fragility didn't bode well for my
database and I've abandoned it.

Despite the product name "FileMaker Pro", it is not actually designed
to catalogue actual computer files. It's simply a database for dealing
with textual and numerical data.

Container fields are only really meant to contain small files for use
within the database itself. Even then, the sound capabilities are
woeful, so Container fields are really only of use for graphics -
things like separate images for the two states of a custom button ("on"
and "off")..

Actually, what I had working was pretty good as to sound. Clicking on
the containers file launched iTunes for the playback. Still, unusable as
a whole. Maybe usable in certain circumstances, as you suggest.

Charlie
--
Nobody in this country got rich on his own. You built a factory--good.
But you moved your goods on roads we all paid for. You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward. Elizabeth Warren (paraphrased)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2018-04-14 18:59:56 +0000, Charles H. Sampson said:

Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:

On 2018-04-09 16:23:16 +0000, Charles H. Sampson said:

Charles H. Sampson <csampson@inetworld.net> wrote:

I'm creating a largish database that contains pointers to music files
(.aif) in containers. The database has reached over 1000 records in the >>>> that use the containers. I've just noticed that over 500 of them now
display the message "The file cannot be found". I got this message once >>>> before when I changed the name of the disc the files are located on.
(They're all on the same disk.) I managed to fix it then, but I don't
remember how. In any case, there have been no new disk name changes.

Any ideas? In previous posts, the feeling was that containers are a
mess.

I've been working on this problem for a while and I've discovered a lot. >>> My big conclusion is that containers are such a mess as to be unusable,
so I'm giving up on this database and reverting to an organization of
audio files that I control.

Now, some details. First and foremost, my problems were caused by
changing the name of the disk (partition) that the files were on. Of
course, I had put only a reference to the files into the containers.

The field store the filepath, so that includes the drive / volume name.
Changing the drive's name means FileMaker can no longer find a drive by
that name.

Sort of. And that's why my script worked up to a point. But suddenly,
the "filepath" returned by GetAsText didn't return the full filepath.
What it did return was so minimally usable that I abandoned my script.

A very quick play with GetAsText shows that it returns two file paths -
a truncated one and the full one.

The Container Field functions don't have anything to obtain the
filepath (just the actual filename), which kind of shows that Continaer
Field file storage / reference hasn't really been fully thought through properly.

Helpful Harry :o)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 15-4-2018 om 00:07 schreef Helpful Harry:

On 2018-04-14 18:59:56 +0000, Charles H. Sampson said:

Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:

On 2018-04-09 16:23:16 +0000, Charles H. Sampson said:

Charles H. Sampson <csampson@inetworld.net> wrote:

I'm creating a largish database that contains pointers to music files >>>>> (.aif) in containers. The database has reached over 1000 records in
the
that use the containers. I've just noticed that over 500 of them now >>>>> display the message "The file cannot be found". I got this message
once
before when I changed the name of the disc the files are located on. >>>>> (They're all on the same disk.) I managed to fix it then, but I don't >>>>> remember how. In any case, there have been no new disk name changes. >>>>>
Any ideas? In previous posts, the feeling was that containers are a
mess.

I've been working on this problem for a while and I've discovered a
lot.
My big conclusion is that containers are such a mess as to be unusable, >>>> so I'm giving up on this database and reverting to an organization of
audio files that I control.

Now, some details. First and foremost, my problems were caused by
changing the name of the disk (partition) that the files were on. Of
course, I had put only a reference to the files into the containers.

The field store the filepath, so that includes the drive / volume name.
Changing the drive's name means FileMaker can no longer find a drive by
that name.

Sort of. And that's why my script worked up to a point. But suddenly,
the "filepath" returned by GetAsText didn't return the full filepath.
What it did return was so minimally usable that I abandoned my script.

A very quick play with GetAsText shows that it returns two file paths -
a truncated one and the full one.

The Container Field functions don't have anything to obtain the filepath (just the actual filename), which kind of shows that Continaer Field
file storage / reference hasn't really been fully thought through properly.

Helpful Harry  :o)

as I wrote before, use a proper textfield to store your filepath. Use a
script to open the file it points to.

Erik

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2018-04-15 06:25:44 +0000, Erik Appeldoorn said:

Op 15-4-2018 om 00:07 schreef Helpful Harry:

On 2018-04-14 18:59:56 +0000, Charles H. Sampson said:

Helpful Harry <HelpfulHarry@BusyWorking.com> wrote:

On 2018-04-09 16:23:16 +0000, Charles H. Sampson said:

Charles H. Sampson <csampson@inetworld.net> wrote:

I'm creating a largish database that contains pointers to music files >>>>>> (.aif) in containers. The database has reached over 1000 records in the >>>>>> that use the containers. I've just noticed that over 500 of them now >>>>>> display the message "The file cannot be found". I got this message once >>>>>> before when I changed the name of the disc the files are located on. >>>>>> (They're all on the same disk.) I managed to fix it then, but I don't >>>>>> remember how. In any case, there have been no new disk name changes. >>>>>>
Any ideas? In previous posts, the feeling was that containers are a >>>>>> mess.

I've been working on this problem for a while and I've discovered a lot. >>>>> My big conclusion is that containers are such a mess as to be unusable, >>>>> so I'm giving up on this database and reverting to an organization of >>>>> audio files that I control.

Now, some details. First and foremost, my problems were caused by
changing the name of the disk (partition) that the files were on. Of >>>>> course, I had put only a reference to the files into the containers.

The field store the filepath, so that includes the drive / volume name. >>>> Changing the drive's name means FileMaker can no longer find a drive by >>>> that name.

Sort of. And that's why my script worked up to a point. But suddenly,
the "filepath" returned by GetAsText didn't return the full filepath.
What it did return was so minimally usable that I abandoned my script.

A very quick play with GetAsText shows that it returns two file paths -
a truncated one and the full one.

The Container Field functions don't have anything to obtain the
filepath (just the actual filename), which kind of shows that Continaer
Field file storage / reference hasn't really been fully thought through
properly.

as I wrote before, use a proper textfield to store your filepath. Use a script to open the file it points to.

That would work if you want the file to be opened in another app, but
not if you want it to work within FileMaker itself. For example, I have
an old Star Wars database I downloaded years ago which plays the theme
tune when you open the database (yes, it's annoying after the first
couple of times, but it's only an example).

Helpful Harry :o)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)