Project management - advice welcomed

[Timbo]

Hi

I'm doing a database in Filemaker for a British University. It started life as an Access database, until I discovered that the University IT dept doesn't support Access! So we decided to do it in Filemaker. I have some experience in Access and other RDBMS, but am new to Filemaker. So far I must say, I'm impressed by what it can do. I'm doing most of the development work on my premises which are a couple of hours jounrney from the University. To help me I have the Coulombre / Price book "Using FileMaker Pro 5" which is very helpful, as is this forum.

I've done a "prototype" database - 3 main tables, several lookup tables. A couple more main tables to add soon. Users have added some data - about 30 record per table.

So now we're starting to think about sorting out the interface. I'd really appreciate some time-saving advice / tips from Filemaker veterans on how to go about this.

Up to now, I have just used the default Filemaker layout for each table, so the user has to switch between the 3 main files. I'd like to work towards an interface which feels to the user like a single application - using tabs to switch between tables / parts of table.

I've noticed that some members have generously posted sample templates in the sample files topic - for example Kennedy's "A Starter Template for a Relational DB ". Is it possible for me to take the database designs I have done and import them into this template or a similar one? Or would I need to start again?

Another question : The University are now using the database in its present clunky form, and want to continue to do so while I develop the interface (including adding / amending data). What's the best way of managing this? Once the interface is done, I suppose I can just import their data into my version. Anything I need to bear in mind here?

Advice / tips gratefully received.

[danjacoby]

My preference is to create buttons to take users from one table to another (or one layout to another, etc.), and place the buttons in the header part of the layout. Obviously, the buttons need to be connected to scripts that perform the various functions you want.

Another thing I try to do is use as few tables as possible -- at least, as far as the user is concerned. Other tables I generally put into a folder so that the user doesn't accidentally open them directly.

Designs, per se, cannot generally be imported directly from one table to another. You can copy and paste graphics. You can copy and paste fields IF the fieldnames are already created in the new table. You can import scripts, but again you already need all the fieldnames, layouts & subscripts, or you'll be fixing whatever you import.

Regarding upgrades, I suggest creating the new interface first, then bring it in and let some people "play" with it before replacing the old version. That way, you can work out any bugs (including user difficulties) before foisting it on everybody; additionally, when you do install it & transfer the data over, some of the users will already be familiar with the new system.

[Timbo]

Thanks, that's very helpful.

Eventually the plan is to put the database on the university's Filemaker server and control access via username / password. Some users will have write access, others read only. Does anyone have any tips on how to go about this?

[danjacoby]

You'll need at least one password that gives full access (including access to Layout mode, scripts, value lists, etc.) -- Filemaker requires it. Keep that password secret. Only people authorized to alter the structure of the files should have it (like you and quite possibly nobody else).

A second password, allowing the user to create, edit and delete records, but no access to the underlying structure, would be made available to those who need it.

A third password, allowing users only to browse and (possibly) print records, would be available to everyone who needs to see the files. You could make this the "default" password, but that's a pain in the neck to everyone who requires higher access -- it's a judgment call.

[The Mad Jammer]

As far as username/password goes, anyone who has Filemaker Pro and access to the folder that your application lives in can get access to the files. Only the password can keep the files from being opened by the end user. In other words, if any end user knows the password to your application, they can gain access. You must be sure that your network security will prevent unwanted users from accessing the files. After that, the scenario that danjacoby described would be a good way to offer access. It is a role based model and works similarly to Win NT security. Of course, if a user who has read only access learns the password of the create/edit/delete role then they will be able to perform those functions. Since the access level to FileMaker is not determined outisde of the application be a separate agency (i.e Win NT), you cannot prevent this scenario from occurring. In any office, users will share passwords with each other even though they are not supposed to. In some scenarios, a user will be granted create/edit/delete access because they are fillnig in for someone else who is on vacation. Once they know the password they will always have create/edit/delete access unless that password is changed and disseminated to only the users who should have that authority.

In the end you must have one administrative password that has access to everything in the Filemaker Pro database files. Also, each database has its own password log. If you want your clients to be able to move seamlessly from one database to another within the application, you must enter the same password into each database. Otherwise they will have to enter a password every time they wish to access one of the related databases. You can define the access rights of each password in each database. For insatnce, if a user signs in with a read only password, say Pass1, to the main menu and elects to go to File A, the same password in File A may have edit capabilities. This is useful for users who may need edit capablilty to a small portion of the application but the not entire application.

When installing FMP on a user machine be sure the installer includes this step. In the Edit->Preferences->Application fill in the User Id box with an actual name or something significant which identifies who is using the program. These names show up in the Server Administration dialog after you begin hosting the application. If you don't the system will use the machine name as the default.

Tha Mad Jammer

And Then...There was nothing.

BTW - My niece is studying in London this summer. She is currently attending Miami of Ohio in Oxford, Ohio (by Cincinnati) majoring in Finance. Unfortunately, I don't remember which university she is at in London.

[The Mad Jammer]

Timbo,

One other thing. You cannot define passwords if the database files are being hosted.

The Mad Jammer

And Then...There was nothing.

[Timbo]

Many thanks to your both - that's very helpful.