How to propely install Runtimes

[swissguy]

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 dlls) - where oh where, that is the question.

Those files must all be in the same dir, according to filemaker runtime rules (as I understand them).

The primary solution file (named, in my case, PV-DB.B01) is the database and that I do not want that in a non-writable install or programm dir. But, on the other hand: on install-time (if installed as admin) I do not know the users actual home dir. I want the actual db to reside in a user-owned dir that is writable but that is neither known at install time nor at development time.

My current if ugly solution is a such: everything is installed in

c:programmsMyFilemakerApp

and after install a batch scrips is run

"Cacls PV-DB.B01 /G Benutzer:F < yes.txt"

that sets the permissons on the database to full for everyone. So later, whatever useraccount there exists on that pc, they can run the solution. Akward, I know but that is why I am here...

What is the proper solution for this? Where do I put the database? I read a lot of forum entries but did not find much, sorry to say.

I also tried to have a simple db wich is not written to as the primary solution file that the opens the 'real' db which lies somewhere else - but script-step open database does not allow filenames in a variable - also tried open url....

Lots of folks seem to deploy runtimes - I wonder how they do that. Do I not see the obvious? - happens to me sometimes.

Thanks for helpful tips.

Regards from Switzerland, Peter

[bcooney]

Welcome, Peter.

I use an installer that lets me put the runtime files (and I keep everything together) in the user's Programs folder. I then create a shortcut on their desktop. I have a "Backup" script that does a Save a Copy As to a folder created by the installer in their Documents folder.

However, Vista changed this for me. As I understand it, Vista renders the Program Files folder read-only. So, I now install the runtime in the users Documents folder.

The Installer should have available as a destination the user's Documents folder--mine does, as a "global variable," if you will.

I've posted several times about runtimes. Perhaps searching using bcooney and runtime will find some helpful threads. Otherwise, ask away.

hth,

Barbara

[swissguy]

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 opens the 'real' db which is in the doc folder. Had no sucess with that because of the open db script step.

Well, anyway....

Btw: I follow your post whenever I find the time - thoughtfull stuff.

Peter

[bcooney]

I do agree, it's uncomfortable leaving the database "exposed" so to speak, in the documents folder. Runtimes are particular about having all their files together.

However, FM isn't like Word in that the "data" is a separate icon. Even with the separation model, "data" and "structure" are combined (I'm ducking any incoming SP responses).

Watch out for multiple users on the same box, launching the runtime. Runtimes aren't multi-user, and this counts. The second user might end up entering data, only to not have it written from cache.

[Søren Dyhr]

I can for the love of, ...well a handfull of gods not see that installs are required for runtimes at all. Runtimes are for "milestones" in a large project to make the customer checkout the functionality and not a tool to produce shrink wrapped solutions.

The solution is crippled by not being multi user and is followed by a cascade of both needed as well as ridiculous supporting files which admitted can be trimmed slightly.

Dominic Goupil have set Filemaker Inc's segment to be groupware and not tools by which you produce agile stand alone solutions for organizations - mom and pop shops perhaps... however such things requires a conversion of the solution using the Runrev aspect of this:

http://www.runrev.com/products/related-software/fmpro-migrator-developer/

...which then will ensure the intellectual rights to the product resides firmly in your hands, no matter how many seats the client over time might feel a need to squeeze in.

--sd

[bcooney]

Soren, I agree, FM Runtimes are not the way to go for a shrink-wrap solution that will be distributed to a wide market. However, when development funds are limited, and the expected user base is a manageable size, then runtimes can be a good answer. Just try producing an application in anything else for under $40K.

[Søren Dyhr]

Just try producing an application in anything else for under $40K.

Producing is one thing another is adapting something from sourceforge... there is a plentora of open source "nearly there" to almost every desire...

--sd

[bcooney]

Nothing off the shelf for the two runtime projects with which I've been involved.

[Mark Reed]

Runtimes are a great shrinkwrap solution for a product that is not meant to be "multi user"

For example, smaller data apps like my magician's database where magicians track thier effects and bookings. The product is designed for the lone magician looking to get organized.

So to say runtimes are not a solution for shrinkwrap - it depends on the target market in my opinion.

Often you can offer a stand alone soho single user app, and if the need arises for multiuser - you then sell them FM Server solution.

I do agree with the fact it is hard to keep the intellectual rights and code private...

[bcooney]

I did say it depends on target market. I'm defending runtimes as a viable commercial solution and not just as a way for a client to review a checkpoint.

[Søren Dyhr]

But the solution the binder produce is a hedgehog of .dll and lingual extensions which are included just to be a safe bet ... but a whopping 10 MB to install, and transfere from a server and thats even before raw data is included with the solution.

Lets take sourceforge thing to run a hotel:

http://sourceforge.net/projects/fgmp-hm/files/V1.1x/FGMP_HotelManagement_V1.12.zip/download

...everything frontend including a manual and being bilingual either in german or english: 3,1 MB ready to run with MySQL hosted hosted somewhere, for say $10 per month. Stick the solution on a memory stick for each employee needed and let them decide which OS to run on...

--sd

[swissguy]

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 I install it in a subfolder of the programms folder). Works well.

But still- I would like to have programms in the programms folder and data in the documents folder...

My solution consists of simple start db (the primary db) with no records that allows the user to start (see startdb.jpg) either the regular pv-db or the archival db (where records of past busines years are stored and wich is seldom used). This start db uses simple open db script steps to open the other db's. Upon start, these first display the corresponding login screen (see

loginpv.jpg). All three db's are bound with the same key, of course - works well.

I tried to have the start db in the programms (the runtime-) folder and the actual db in a writable place (documents) but the start db cannot open those because the open db script step does not allow variables containing the calculated path which is not known at development time.

Only import/export steps allow this. Also tried open url but this does not help. so

a) why is this so?

: is there a way around for the open db step?

Regards from Switzerland, Peter