Working on Solution while being served...

[vanderark1]

I am updating our 20+ file solution daily. It is being served with Filemaker Server and we have about 15 users.

Obviously, I deal with Define Field problems (need everyone to close the file to define fields).

My question is, are professional developers NOT working on their solutions when users are using it? I have no choice. I can't avoid updating every few days, because we are constantly deciding on new features we want incorporated into the solution.

What is the best way for me to do this? Right now, when I do major changes, I work early AM and late PM and on weekends. I shut it down in the office and VPN in, move the files to home and move them back.

Should I copy the files, then let users continue working while I work on the copies, then clear all info in mine and import their info into mine, then make those the files we all use?

Importing 20+ files worth of data (some with 40,000+ records) seems very risky and time-consuming. There must be something I am missing!

[EddyB]

Hi,

Your 2 solutions are the only solutions at the moment i.e. Geting everyone to close the files, or making copies then importing the data.

I believe this is meant to be changing in FM 7 so that the files can be worked on whilst users are still connected

Regards

Ed

[dkemme]

I will typically define a few fields of each type, text, number, global text, global number... with generic names to allow me to to a little modifications without changing field definitions. Then when everyone is off the files I will rename them to the correct fields and then create new fields to grab when needed. Also, if you need to add a few quick fields in just one database, you can send a message via server to the users what you are up to, open the define fields database, ask them to log off just that file for a few minutes, with little true interruptions.

FM7 will make all this much easier!

[stanley]

With my clients I usually have a particular time of the week to shut the server down for maintenance - most weeks it doesn't happen, but they get used to the idea that some Tuesdays (or whatever) the server is down for an hour or so. Then, when I'm asked to do alterations which will require Define Fields, I tell them to let everyone know that Tuesday at lunchtime (or whatever it is) the server will be down for an hour...

-Stanley

[EddyB]

This is the way that many developers do it I imagine, either that or work on the DB out of hours...

I normally carry out changes on a Friday afternoon, I do this for 2 reasons. The 1st being that not much work gets done by the users on a Friday afternoon! and secondly if anything went wrong, I would have the weekend to recover a backup before any users experienced any significant downtime.

Ed.

[vanderark1]

Thanks for your replies.

I guess I am not far off in my habits then. I also have been identifying a few generic fields of most types and that works good. However, it obviously doesn't work with calculations, which I always seem to need!

dkemme: what do you know of FM7 that makes you think this will be addressed?

I stayed on FM 5.5 becuase there were minimal reasons to go to FM6 for our needs. I didn't want to replace 20 seats of 5.5 without a good reason.

[Steven H. Blackwell]

Having the technical capability to do something, e.g. define fields on a hosted file--and actually believing that it a good idea to do that are two entirely different things. Obviously the safest environment for development is as the host on a sterile machine.

Using various separation techniques, the Tier 1 data layer and much of the Tier 2 business logic layer of a solution can be separated from the Tier 3 presentation layer. This makes "live" development a lot easier.

Steven

[vanderark1]

Now I think you're way out of my league.

Are the separation techniques you mention something for which 1000+ page books are written, or something that is easily understood by non-pros?

[Mariano Peterson]

Using various separation techniques, the Tier 1 data layer and much of the Tier 2 business logic layer of a solution can be separated from the Tier 3 presentation layer. This makes "live" development a lot easier.

Unfortunately, FileMaker is not well suited for this. This approach typically involves extensive use of portals, which can be ackward for users to work with (particularly scroll through), and can quickly degrade performance in many situations. Further, FileMaker based separation techniques usually involve a presentation file, with the idea that UI changes can be made offline and the presentation file swapped easily and quickly without having to re-import data from the data layer. While this approach sounds good in theory, it is rare when application mods are limited to superficial presentation changes that don't require modification to the under lying data structure. [in my experience,] Database changes usually stem from the need to track more data, track existing data at a more granular level, and extend the database to track different kinds of data (to accomodate the needs of a growing user base). Most of these situations call for the underlying data structure to be altered, negating the benefit of a presentation layer but incurring the associated cost.

I agree on the other point, that it is safer to udpate field definitions on a development machine as opposed to on the production server.

[Steven H. Blackwell]

The Separation Model (TSM

[dkemme]

Here's a link to ThinkSecret's news on FM7

http://www.thinksecret.com/news/filemaker7shipping.html

CHEERS.

[vanderark1]

Interesting article (especially if you follow the links to features). Sounds like upgrade from 5.5 to 7 will be well worth the effort and expense (unless the price increase too much).

Thanks!

[stanley]

Very interesting. It looks like we'll all be doing a whole lot of re-learning soon.

-Stanley

[dkemme]

Here's a bit more, sounds like we learn the rest tomorrow when Filemaker is expected to make an official announcement.

http://www.thinksecret.com/news/filemaker7details.html