![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
| Gary Vellenzer wrote: I'm a newbie, publishing my first DB on CD for a client. The DB is large (several hundred Meg), so the client feels the main DB should stay (as read-only) on the CD, with all actions that actually change the DB taking place in subsidiary databases that are moved to the hard disk by an installer. I've simulated this by making the main database read-only on my hard disk, and the code works in Filemaker. Now my question: in a bound runtime, how do I get the runtime to recognize that it should work with the moved files on the hard disk, not the original ones on the CD? Am I missing something obvious or am I approaching the whole problem from the wrong perspective? I think you're heading for a world of pain myself... if your users are anything like mine, they will always try and play with the wrong thing, and then complain that they couldn't write their changes to the system. Yes, several hundred meg takes some time to copy, but then they've got the CD archive, and a working version of the database system, which they can use without worrying about anything else. My 2c anyway I was intending to give them the option of copying the database or |
#3
| |||
| |||
|
|
In article <3F25E0A5.91BA36C5 (AT) usyd (DOT) edu.au>, tbooth (AT) usyd (DOT) edu.au says... Gary Vellenzer wrote: I'm a newbie, publishing my first DB on CD for a client. The DB is large (several hundred Meg), so the client feels the main DB should stay (as read-only) on the CD, with all actions that actually change the DB taking place in subsidiary databases that are moved to the hard disk by an installer. I've simulated this by making the main database read-only on my hard disk, and the code works in Filemaker. Now my question: in a bound runtime, how do I get the runtime to recognize that it should work with the moved files on the hard disk, not the original ones on the CD? Am I missing something obvious or am I approaching the whole problem from the wrong perspective? I think you're heading for a world of pain myself... if your users are anything like mine, they will always try and play with the wrong thing, and then complain that they couldn't write their changes to the system. Yes, several hundred meg takes some time to copy, but then they've got the CD archive, and a working version of the database system, which they can use without worrying about anything else. My 2c anyway I was intending to give them the option of copying the database or leaving it on CD. |
|
But the option of not taking up disk space can be useful, so I'd like to offer it if it can be done in Filemaker. |
#4
| |||
| |||
|
|
Gary Vellenzer wrote: In article <3F25E0A5.91BA36C5 (AT) usyd (DOT) edu.au>, tbooth (AT) usyd (DOT) edu.au says... Gary Vellenzer wrote: I'm a newbie, publishing my first DB on CD for a client. The DB is large (several hundred Meg), so the client feels the main DB should stay (as read-only) on the CD, with all actions that actually change the DB taking place in subsidiary databases that are moved to the hard disk by an installer. I've simulated this by making the main database read-only on my hard disk, and the code works in Filemaker. Now my question: in a bound runtime, how do I get the runtime to recognize that it should work with the moved files on the hard disk, not the original ones on the CD? Am I missing something obvious or am I approaching the whole problem from the wrong perspective? I think you're heading for a world of pain myself... if your users are anything like mine, they will always try and play with the wrong thing, and then complain that they couldn't write their changes to the system. Yes, several hundred meg takes some time to copy, but then they've got the CD archive, and a working version of the database system, which they can use without worrying about anything else. My 2c anyway I was intending to give them the option of copying the database or leaving it on CD. All good... until you remember that FileMaker will finf *any* file of the correct name if it is available. If there's one on the HD and one on the CD, it will pick one of the two. And I don't believe anyone has really worked out *which* one of the two it will pick... But the option of not taking up disk space can be useful, so I'd like to offer it if it can be done in Filemaker. Disk is so cheap these days. If a couple of hundred of meg is a problem, then they'll also be using FM 3 ;-) Make the installer copy the lot first time. Be done with it. Webko |
#5
| |||
| |||
|
| Gary Vellenzer wrote: In article <3F25E0A5.91BA36C5 (AT) usyd (DOT) edu.au>, tbooth (AT) usyd (DOT) edu.au says... Gary Vellenzer wrote: I'm a newbie, publishing my first DB on CD for a client. The DB is large (several hundred Meg), so the client feels the main DB should stay (as read-only) on the CD, with all actions that actually change the DB taking place in subsidiary databases that are moved to the hard disk by an installer. I've simulated this by making the main database read-only on my hard disk, and the code works in Filemaker. Now my question: in a bound runtime, how do I get the runtime to recognize that it should work with the moved files on the hard disk, not the original ones on the CD? Am I missing something obvious or am I approaching the whole problem from the wrong perspective? I think you're heading for a world of pain myself... if your users are anything like mine, they will always try and play with the wrong thing, and then complain that they couldn't write their changes to the system. Yes, several hundred meg takes some time to copy, but then they've got the CD archive, and a working version of the database system, which they can use without worrying about anything else. My 2c anyway I was intending to give them the option of copying the database or leaving it on CD. All good... until you remember that FileMaker will finf *any* file of the correct name if it is available. If there's one on the HD and one on the CD, it will pick one of the two. And I don't believe anyone has really worked out *which* one of the two it will pick... But the option of not taking up disk space can be useful, so I'd like to offer it if it can be done in Filemaker. Disk is so cheap these days. If a couple of hundred of meg is a problem, then they'll also be using FM 3 ;-) Make the installer copy the lot first time. Be done with it. I've discovered a wonderful thing. Filemaker runtimes (Developer 5.5) |
![]() |
| Thread Tools | |
| Display Modes | |
| |