Developing a Commercial App?

[Mark L]

Issue Summary:

I

[transpower]

1) a run-time version can be used in a multi-user setup provided each user has a copy of FileMaker

2) you're responsible for updates (you would explain how the user would import old records into the new tables)

3) password protect Developer--follow FMI rules in this regard, on your About screen

4) just send your new tables with zero records and instruct users how to import their current records

5) take your solution to a medical conference and see if any doctor can trash it!

6) Access or VB would be much more complex

7) you probably should beta test the product for several months before releasing it

[Mark L]

Transpower - thanks for your input. A couple of questions on your comments:

- On #1) "A run-time version" can be used, so long as each user has a copy of FM" - great - that's good enough; but I just want to confirm that no one is going to be able to "see" my coding - it would still be compiled, right?

-On #3) I'm not sure what you mean by "follow FMI rules in this regard, on your About screen" (Pardon my ignorance - what's "FMI" ?)

[color:"blue"] Thanks again - and everyone else - please give me your thoughts on my inital posting too.

-Mark L.

[Sky Dancer]

Using Developer to create a "stand-alone" solution compiles it into non-FileMaker-human-readable form...at least it's not readable by the average user. (but....NOTHING is unhackable! Ask Microsoft! They've been doing this for 30 years and ALL of their copy protections have been broken!)

"FMI" is short for "FileMaker Inc." When you distribute your own solutions, they want you to put some disclaimers into your "About" screens and user agreements that tells YOUR users that FileMaker is not responsible for any passwords you put into your solutions to protect them. FileMaker will not try to recover any passwords YOU put in your solution. That's all. (A 'sample" of this text is provided in the Developer manual for you.)

[Oldfogey]

2) I've never seen any but I wish I could find some!! Basically, it's a matter of organisation. You just need to keep a record (bits of paper, books, FMP db, etc.) of EVERY change/desired change/bug with how and when you fixed (or are going to fix) it. I use a WordPerfect file. Group these items by version number. This means you might need to move some very difficult items to the next version-to-be. You also need to keep your user manual(?) up to date with the modifications. This adds zillions more creepy-crawlies to your nightmare.

I've only had to do this version thing in a big way once and that has driven me crazy. I'm up to V2.6 in 12 months. Fortunately, that doesn't represent 15 updates. In my misguided optimism, I occasionally rounded up - "Yeah, make it 1.5 and we're done."

V1.0 to about V1.9 were bugs. From then on, it has been a mix of bugs, minor change requests, and major change requests. This app is for a customer with franchises; we send/deliver the updates to the franchisees.

THE biggest problem I've had (after my fantastic ability to create bugs) is getting the customer to tell me when things are wrong. He usually tells me just after I've burnt a new set of CDs.

We have a printed manual (Word document) and it also has version numbers. Around V2.0, I got the manual version number and package version number in sync.

The manual has a list of changes to the manual at the front; a few of the changes read "Change in version number to match package version. No other changes."

4) I think Transpower is a little optimistic. It is unreasonable to expect users, especially professionals like doctors who think every other profession should be perfect, to import records. First, they don't know what a record is. Second, they need a short course to understand where the stuff is being imported to. Third, they'll stuff it up. Finally, "Duh, what's 'import'?"

You need to create a script that will import the old data into your new copy.

Sounds easy but it isn't. It can be done - I've done it. Briefly,

1. store the old next serial numbers in each table/file

2. rename the old application folder

3. copy the new application version to the HDD

4. run a script in the new version to import the old data.

In a nutshell, what you are planning to do is possible and quite feasible. Unlike most IT projects it will take about ten times, rather thn five times, the effort you anticipated.

Have a look at the 'Separation Model' forum. In theory, this makes updates a piece of cake.

Check out the 'Installers'. Windows Installer is probably the most widely used. I use Tarma Installer. There are lots of others. These make it simple for the user to install your package. You've installed packages, haven't you? You do not have to do anything much because the authors have used an installer.

No doubt you are doing this for the good of mankind but, in the unlikely case that you are interested in money, set your pricing to include the cost of a FMP licence for each user. I can't help thinking "Buy this beaut package for just $45,000,000 and get FileMaker Pro FREE!!!" Seriously, I generally include the price of FMP in my quotes and tell the prospect why.

Finally, no reflection on your ability but I bet your carefully developed specifications are about 70% correct.

[Oldfogey]

Transpower,

Are you 100% sure about the sharing of FMD Runtimes given a copy of FMP? Surely FMI would make a 'thing' of this. Inability to share runtimes is one of the biggest drawbacks to making FMP the top application distribution package.

[pjdodd]

I wish runtimes could be shared....the database file can be opened with anyone who has a copy of FM,

but,

*** it cannot be shared by any known means if the runtime application has opened the database file first***

or

**if the database has been opened by Filemaker and then the runtime attempts to load it. ***

Ive tried various combos and runtimes cannot share files. Bummer huh?

[Mark L]

Oldfogey-

Thanks so much for illuminating some earlier points and touching on others I never even thought of - it is greatly appreciated.

Thanks,

Mark L.

[Mark L]

pjdodd-

Thanks to contributing to the discussion.

So how would one - or could one make a compiled FMP apps for multiple users - only with the dedicated FMP Server App?

Thanks,

Mark L.

[Oldfogey]

Mark L,

In a nutshell, you cannot share runtimes. The main purpose of a runtime solution is to make it unnecessary for your customer to own FileMaker. If the customer is prepared to buy FMP, then there is no need for a runtime.

The runtime FMP files can be shared like any other FMP files but, as pjdodd points out, once the runtime gets involved you've had it. (In case you haven't had a good look at a runtime solution, it consists of a very large .EXE file, your base FMP files with a different - not .fp7 - extension, and a heap of other files - dll's etc.)

You really have two options -

1. Sell your customers FMP with the package and protect your DB with good password security. You can then have the DB shared for a small number of users. Large numbers will require FMP Server - a different ballgame again.

2. Market a standalone runtime with no sharing.

I have no experience with web apps but I believe that you publish part of your DB on the web and users can share that but it is not a 'runtime'; you have FMP running in the background.

[Mark L]

Oldfogey-

Thanks again for your insight.

I guess my biggest concern is that if I were to distribute a multi-user version of my application - that it would easily be "decompiled" - since it really won't have the protection of being compiled. My "gut" is still concerned that relying on good passwords wouldn't protect the application the same way as having it compiled. I guess that leaves me with option #2. (But if #2 is successful - there will be pressure to make it multi-user.)

If you have any more thoughts - I'd be happy to hear them.

Thanks again,

Mark L.

[Mark L]

Oldfogey-

Just wanted to update you - I checked out the Tarma installer - it does seem really "simple" - although honestly, it's still a bit intimidating to a first time developer.

Is there a downloadable manual somewhere - I can just find a FAQ and a long "Common Tasks" list.

Thanks in advance,

Mark L.

[Vaughan]

Mark L: runtimes are not compiled, since FMP is not a programming language. The runtime is a royalty-free single-user copy of FMP with all the development tools stripped out.

The Developer tool also offers an option to permanently prevent modification of database structure, which appears to be independent of the runtime creation (this is Dev 5.5 I dunno about later versions but assume they are similar). This prevents anybody even the developer from altering the database in FMP ever again, so be sure to keep a clean open copy if using this option.

[Mark L]

Vaughan-

Thanks for the clarification. My concern is less about the database format (which it sounds like they could see - but not modify,) but about people reading the "business rules" - which would mostly be contained in its scripts.

If you have any thoughts on this, please let me know.

Thanks again,

Mark L.

[Vaughan]

FMP 7 has much better password security than earlier versions. Unless you give people a "full access" password they won't be able to see scripts, layouts or field definitions.

[Mark L]

I guess I would have discovered that sooner or later - but that's the best news I've heard all day - the gives me quite a bit of relief!

Thanks Vaughan!

-Mark L.

[Oldfogey]

Mark,

Sorry for the dealy. Been working.

You're right about Tarma being a bit intimidating. You should see some of the others! I use the help file; it's OK as these things go.

I'm still learning about Tarma; it seems to do some weird things occasionally.

[Mark L]

Oldfogey - Thanks for getting back to me one way or another. I'm definately doing this project - so all your input is really valuable.

Thanks again,

Mark