• Container Problem: File Cannot be Found

    From Charles H. Sampson@21:1/5 to All on Mon Apr 2 17:41:48 2018
    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)
  • From Helpful Harry@21:1/5 to Charles H. Sampson on Tue Apr 3 13:36:18 2018
    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)
  • From ursus.kirk@gmail.com@21:1/5 to All on Tue Apr 3 10:09:45 2018
    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)
  • From Charles H. Sampson@21:1/5 to Charles H. Sampson on Mon Apr 9 09:23:16 2018
    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)
  • From Helpful Harry@21:1/5 to Charles H. Sampson on Tue Apr 10 09:40:48 2018
    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)
  • From Charles H. Sampson@21:1/5 to Helpful Harry on Sat Apr 14 11:59:56 2018
    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)
  • From Helpful Harry@21:1/5 to Charles H. Sampson on Sun Apr 15 10:07:04 2018
    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)
  • From Erik Appeldoorn@21:1/5 to All on Sun Apr 15 08:25:44 2018
    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)
  • From Helpful Harry@21:1/5 to Erik Appeldoorn on Sun Apr 15 19:24:49 2018
    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)