Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About swissguy

  • Rank
  • Birthday 10/14/1950

Profile Information

  • Gender
  • Location

Contact Methods

  • Website URL
  1. Hi In the meantime, I have figured out what the problem was. I will explain shortly. I have FM 10 Pro Adv installed on my Windows Vista Laptop and on my Macbook Pro. Have an app with 3 db's, the main-db having >10 tables that I developed over the years and have 7 happy customers (admin software for psychotherapists), app works well and I have no problems. I distribute runtime versions and have developed elaborate scripting solution to update existing runtime versions in the fields - works great. Have just a few lines in the code that deal with platform differences - mainly filepat
  2. Hi I have am FM application that i developed over the years - started with FM 5 way back... This app needs updates about once a year due to customer requests. Now, for some time while developing, I run a FM recover several times a day since I have found that while developing FM sometimes screws up my database for unknown reasons - I am not talking about crashes and the like. Just regular work on scripts and layouts. I have had this in FM9 Pro Adv and also in FM10 Pro Adv. Came across this issue by chance. So I do a recover simply to check it out and if that reports OK I save the current
  3. Hi again Sorry to bother you all.... just found the solution by browsing thru some of the posts here. I inserted a Refresh Window [Flush cached join results] and that does the trick. Did not find this necessary because the print window is being closed after printing - and another one might no be opened for a long time during the users session. Regards, Peter
  4. Hi My FM10 Application ist separated into two Modules: the application module itself with all the tables and the data and a print module that contains all the logic und layouts for printing (list of invoices and single invoices or clientslist, among other things). I ship runtime versions to my (few) clients. That allows me to change printlayouts and to redistribute the printmodule (that contains no customer data) without touching the application runtime file - no hassle with re-importing the customers data. Works well and makes life easier if change requests for printlayouts come
  5. Hi Barbara Well that is good to know, I must have been misinformed. I might try to skip the export step but have to think about it cause I like my migration step and for that I need the version number - but come to think of it, that is stored in my system table which is imported - so I have it after import. Have to check it before overwriting it with the new value.... Well, it is the same with every programm you write: one always finds ways to improve it, it is never finished. Peter
  6. HI I just added a post in an other group as this issue (update runtime) was discussed there. Here is the link http://fmforums.com/forum/showtopic.php?tid/209924/ Sorry if this was the wrong place to place my post. Peter from Switzerland
  7. Hi I followed this thread since I also have a solution to update my runtime. It is as such: After installing a new version the user has to "import old data" from the old db (which is moved into a known location before install). An convenient update layout is provided to do this. I do these steps in the import script: - relogin current db with an general export account (with reduced privileges to import and export) - open old db (is opened with this account, according to FM rules) in the known location - call an export script in the old db to export all tables in a loop to a
  8. Hi to everyone Thanks for all replies - however, since the number of customers for my runtime solution is between 10 and 50 I am gonna stick to FM runtime. Also, with todays ample diskspave I am not overly concernd about the size of the distribution nor with the exact number of files it contains. Therefore I am coming back to my original question, where to install the runtime folder. I will follow bcooneys advice and will install it in a subfolder of the users documents folder. That way I can get rid of my cmd Script to set permissions (currently this is needed after install because
  9. Hi Barbara thnx for your reply. Yes, my installer does have the option you mentioned. And yes, I might consider installing everything in the docu folder. And I would have to tell the user that he needs to install my app with his regular account, disregarding an admin account he might also have. Yep, I will give it a try - seems obviuos now that you mentioned it. But, of course, it is still a bit ugly: programms ought to be in the programms folder and data should be in the doc folder. That is why I tried to have a small primary solution file with no records, just a script that open
  10. Hi My problem: How to properly install am FM9 runtime solution on an PC (single user on his own machine - I will deal with Mac later...) that works either with users whose single account is an admin account and also for other, more grown up users who have a separate admin account (as one should) to install apps - that is what I have been trying to do for some time. Searched different forums but to no avail. I am using an installer (CreateInstallFree) that installs the runtime (filemaker-database/the primary solution file, the database-engine (exe) and all other runtime related files und d
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.