Somewhere, out there....

[mborgens]

In my online searchings I have seen FM websites that I would call well done websites, but I haven't seen what I would call online databases. Are most people using FM to display database info online verses an interactive website which has intensive data input? Can anyone direct me to a website?

[Vaughan]

I have set up a couple of systems that allow users to view and add information. In both cases they were messaging systems. Unfortunately both live on an intranet behind a firewall...

The web and client interfaces have different strengths and weaknesses: web is good for viewing information and adding records, but the lack of record locking makes it IMHO a poor choice for systems where record data is being changed a lot. (Yes I know the modcount function but that only warns that the horse has bolted, it doesn't keep the door closed.)

So for me, simple messaging systems are great over the web. Systems that require decent data integrity, reporting, editing and updating I prefer to do through the FMP client.

I should add that one system could use both interfaces (client and web) for different purposes.

[mborgens]

Thanks, that's what I assumed might be the answer, but was hoping for a different answer. Do you think this might change in the near future?

I really appreciate these boards. mb

[Keith M. Davie]

Vaughan, you wrote (and I've seen similar before), "...but the lack of record locking makes it IMHO a poor choice for systems where record data is being changed a lot."

I really don't get this. Locking does just that, it keeps others from accessing a record while locked. So in a FMP client solution such as you advocate, if the record is locked and five others are waiting to access that record - for whatever purpose - they are precluded and must wait. (Employee cost gets involved in this idletime.)

Now it is suggested that this feature is useful where "record data is being changed a lot". Why? Or, how?

To keep 5 (say) employees from editing the same record simulatneously? Would they all be making the same edit? Unlikely I suppose. Would they be editing different features of one record such as sales, auditing, accounting, advertising and scheduling all at the same time? Or would these departments each have their own record base?

What is the scenario which makes keeping people from accessing record data which they have need to access so attractive?

With a browser one can access a record for review, leave it on the screen for hours, and come back to it. It's still there. Similarly, one can access a record vis a vis the browser for editing. That record could similarly sit on a screen for hours before being acted upon. Others could still access the same record through a browser for whatever purpose because the record is not locked. Instead the data of the aforementioned edit is entered in a stateless manner and then dumped into the db in an instant.

I really don't get the "advantage" of locking people who need to access data out of that accessibility. I am hopeful you can clear this up for me.

[Vaughan]

Record locking is an important part of multi-user integrity. It's a way of making sure that all changes are "serial" rather than "parallel". As an example, somebody on the forum is working on auditing record changes: this system will only work if records are changed serially. If people are changing fields simultaneously, they cannot be tracked (the task becomes more difficult by orders of magnitude).

Where records are only ever going to be "single user" or "written once never changed" the web is great.

[mborgens]

Record locking is frustrating. I developed a solution for schools and it seems everyone wants to complete their section of the file just before the meeting, even though very few fields are overlapping. I think I remember being told that field level locking would take way too much processing power. But couldn't FM lock the field and check to see if anyone else has locked the field just prior to posting?

[scratchmalogicalwax]

I build online recruitment sites for UK blue chips using WebSTAR, Lasso and FMRo. Works very well but I would find it much harder to achieve with FMPro alone. We can build powerful sites in half the time and at 66% of the cost of our competitors (the actual build cost to us in time is less than 30% of doing the same with ASP or PHP).

Our busiest site took over 7000 applications in one recruitment campaign and we currently have 6 live campaigns.

[Keith M. Davie]

Vaughan, (et al) thanks for the responses. Right after posting my query a strong wind blew my broadband antenna down and I