rigman

Well I'm pretty sure I had filled that profile in the beginning but it's been years since I've been in this forum. Thank you very much for the tip on the GiveAccess software. I had tried changing registry without success. Of course if the user does this manually then this is no trouble but my solutions cater to the non-power users so this has to be resolved from the install. I will give it a try but I see they have the 32bit and 64 bit versions so I'm wondering if I should use the 32 bit version when I am installing the 32bit runtime files in a 64 bit Windows O.S. system... have you had experience with these situations? It would be great not having to deal with detecting the bit versions of the O.S. to launch the correct version of GiveAccess.

WOW. I can't believe FM has not addressed this as of version 12v4... It's must be a known issue for years now. Every decent windows application that needs to write data in windows 7 or 8 will write to the %appdata% directory. Under the new security policies Microsoft explicitly protects the program files directory, it should not host any user modifiable files. The database files should be installed in appdata, while the runtime should be in the program files folder. Problem is how does the runtime EXE know where the datafiles are now... big bummer for those needing to deploy commercial apps (runtimes). Having an installer run and then having to give your customer instructions on how to explicitly provide admin rights to the app so that it runs right is just ridiculous. Has anyone found a work-around this issue? (while keeping the runtime in program files).

Considering 4d here too. Here's a couple of questions for you all, What other development platforms are you seriously considering? And what specific features are you looking for in those new platforms? For me, bringing true multi-user capabilities to compiled or runtime generated applications is a must, which is basically non-existent in FM. Also high on my list is the ability to edit true code and provide a good environment for teamwork application development. I think that the general feel for some of us is that leaving filemaker is not a question of if, but rather of when. I also plan to keep it around for a while mostly for legacy application support.

Same thing happening here on FM10 server, so I guess it is the standard behavior of the admin console. For a multi-user solution it would be much better to have the actual account name displayed in the console rather than the registration name(or both if one wishes to). I noticed that you can still see the account name of the user by clicking the registration name of the active session but after a while it gets tedious (look for it just below the middle of the app).

an alternative would be to try a RAID mirror. Either a hardware or software RAID would do it. Has anyone tried this?

So what did you do eventually?? Did you ever considered eliminating the AM PM "visually"? Just hiding it by placing an object over it, like a filled square for example... I know its cheap and easy : But it could work for you depending on what you want to do.

interesting... I'm trying to do the same. There should be a way of doing this without using set field, which seems overkill for a table with 488 fields. In my case, I need to archive the old records that will no longer be used. By transfering those to the second table, users will still be able to view the old data in a second layout, while clearing the main table from the records no longer needed there.

have you tried to read the data? If FM won't read it, try excel or access. you could then re-import into FM from those. I used to develop under Dbase, and when clipper came out I recall hearing it handled the DBF format, (not sure if this was a default for all solutions) so I could be wrong...

Hi Guys, I'm new to the forums and already loving it. Here's a little contribution. It uses send event (as mentioned previously) and the cmd command interpreter. Since cmd is built into windows (windows NT and upwards if I recall correctly) it should work across all XP and Vista machines... Maybe the solution can be improved as to show the actual available drive letters? I haven't looked at this in detail but have a feeling that it could be done natively... bye :B create_folder.zip

Hello, do not despair. What you want can be done without even using the conditional format functions, you just have to get creative. I did this a while ago on a Fm4 solution. Basically I used this to launch an external program by clicking on the button (in my case I was launching a second runtime solution from a main one). The button would show up on the layout only if the file of the second runtime was present in the system (the user would install the second solution and the button would show up on the first solution, ready to be launched). I recall I used relationships (yes) and probably a portal (I think the button was inside it)... Whenever I wanted the button to appear on the layout I'd make the relationship true, and false to make it disappear. It worked perfectly. Sorry that I can't recall the specifics now, it's been a few years. I'd have to browse through the old solution code. If there's enough interest I can extract an example from it, but the relationship thing is the key. cheers.

Hi Vaughan, Glad to learn that others have already taken a similar approach. Personally I think it is an excellent way to deal with updates, so it may be exactly what the original poster is looking for. In my case I can comment that back in 2002 I released a major app for the vertical market using such separation methods. Over the years this has allowed for extremely easy front end application changes, including GUI modifications, the addition of new layouts and even the incorporation of new fields. (I say new fields because, back then when the initial fields were defined in the database, extra fields were added just in case the GUI would need to incorporate these for future use.) This has really eased the introduction of the newer versions. Also, from a technical support perspective the amount of incidents has been extremely low to the point that as of this date we've had zero data losses that we know of. The minor troubles that our clients have experienced so far have been a couple of file corruption issues on the application modules without any damage to the data files whatsoever. Resolving these involved replacing the damaged files with a fresh copy, with no import needed on the user side. Looking back almost 6 years into it all and I can't think of any other better way to deal with this particular deployment. For me, the peace of mind has been worth many times the extra development spent in the beginning.

Hi John, Your post encouraged me to register in order to share some of my experiences regarding your question. I've been using the FM developer platform for some time now, beginning with version 4. One of the best ways that I've dealt with upgrades is by isolating your solution. What does this mean? It means basically separating your data from any layouts/script, etc generated in the application. This means all fields that will store user generated data go into one (or many) files (which I call data files), while the rest of the stuff (your application basically) goes into other files (I call these application modules). This changes your programming paradigm quite a bit as you need to perform a bit of work defining relationships to link everything in the beginning, however the advantages in my opinion far surpass any initial complexities that this may present (actually it involves just a little different programming than what one can find in the books) The benefits of this are: - Transparent application upgrades. This means that if you modify an application module (for example change a layout or script in it), then bind and send this file to you user for him/her to overwrite the old one, there will be no importing of the records. Therefore data can be instantly accessible. Under certain circunstances where the application module needs to be able to browse between records (as when using the little notepad icon in the top left), one needs to only recreate the index of the application module (that is, create all associated record identifiers with the data file) and not a complex import process. In other words, there should be a script in the application module that detects whether application and data files match. If they don't it will recreate the exact number of records and import the id number of each record. This process can be completely transparent or one can choose to notify the user that the index needs to be recreated. -Increased stability in the final solution. Because data and application are separate files, data structures remain safe should there be a problem at design time. (Actually I decided to explore this type of development since my solution had grown so big (many layouts) that I started to have file corruption issues in version 4.0. Once I segmented the application into modules and kept the data structures isolated those problems were gone forever. -Super easy data backups The user needs to backup only the data files, not the whole application! this translates into smaller and faster backups. -More efficient restores For the same reasons above... plus, the restore does not replace the application version with an older one contained in the backup! Application remains intact. I have thought about going into the details on the techniques I use. Perhaps I can start sharing those over these forum... I've also thought about writing some guide or publishing a webpage... but time issues have kept me away. Hopefully this info will be of help to get you started in this direction, should you decide to do so. I would also be very interested in finding out what others have done regarding this topic. cheers, Robert.