5.5? why is everyone so quiet? post your thoughts here...

[Jodin]

i for one was pretty excited when i saw the announcement for 5.5 and i can't believe how quiet everyone is being here. can anyone shed more light on the developer features? i have yet to play with a copy but the thoughts of record level security, get field, and a script debugger are making me nearly salivate. is it that FM is finally giving us developers something to play with?

so what's the silence? post your thoughts on 5.5 here and try to focus on the functionality and not the upgrade price if you can. i'll try to get a demo and check it out soon but i am swamped with dev in 5.0 and don't want to tempt fate with a 5.5 install right now.

jodin

[kraftyman]

I wasn't really complaining about the price as much as the lack of substantial improvements. It should have been v 5.04.. ( in my application, I spent quite a long time working around the limitations, and 5.5 does nothing much to improve the existing problems.)

[kraftyman]

I don't know what hapened to the rest of my message. I tried to edit it and the changes didn't get through. Take 2

I wasn't complaining about the price as much as the lack of really substantial improvements. The hype on the website is way out of keeping with the product. It should have been v 5.04.. ( in my application, I spent a long time working around all the limitations, and 5.5 does nothing much to improve the existing problems.) If you look at the differences between 5.03 and 5.5 it really has a bugfix flavour. 5.5 is still a three legged dog in the same places as 5.03. There are a couple of things you could do easier in 5.5, but if FM Inc. really did want to make a big difference, they would take a look at what plugins are popular. This is what people need and are willing to pay for. This is what needs to be included in the new version. They should tak to these clever programmers and incorporate the code. So bring on proper SQL communication, proper conditional lists, proper event driven scripting, proper variables, proper dialogs, proper file handling , proper OLE support etc etc etc.

I long for the day when data can be divorced from the interface, so I don't have to worry about importing/exporting thousands of records, each time I want to change a layout. I salivate over the thought of saving my scripts as a separate entity from the data, and e-mailing them to my friends, so they can import it directly into FMP. I dream of being able to run a query, without having to design 15 layouts in the process. I want to preview the record I just browsed without having to "find all, omit and then show omitted". I want to store variables without having to create global fields which choke ODBC clients...

Ooops, apologies.. Did I just spit the dummy? I really didn't mean this to turn into a diatribe

It's fun using my "necktop" to create workarounds, and creating solutions.

I just wish FM Inc. didn't blow their trumpet so loud, and pat themselves on the back so much - because it aint that good...

( example FMP5.5 >>FM mobile ready - what a joke! FM mobile is a waste of space on my Palm. For half the price you can actually get a proper database in HanDBase or ThinkDB or JFile)

I really appreciate FM Inc's efforts, but I'll wait for their next baby, maybe that one will have all the legs.

[Gogargirl]

Hey, Kraftyman -

Much of this is beyond me as a self-taught junior, but learning stuff from the Forums has definitely helped me avoid certain disaster and something you said there caught my eye...

quote:

---

I long for the day when data can be divorced from the interface, so I don't have to worry about importing/exporting thousands of records, each time I want to change a layout.

---

Are you saying that layout changes shouldn't be made in a populated db? I know I've had problems with FM crashing when I'm in the middle of writing a script - usually copying and dragging a script step. Where can I find out more about avoiding crashes?

[kraftyman]

I love these forums too.. I've learned heaps and haven't lost as much hair as I could have. I'd rather post a reply in a different forum, but I'm not sure which - one of the administrators could redirect this post and/or correct me here. In general, many design changes can be done in your original file. It should not harm your data. I'm not sure why FM should crash, maybe you are producing a calculation it cannot complete, or an endless loop ( ie waiting for a condition that will never happen). As a safety measure, it is always better to fiddle with interfaces away from the data. It is a major issue if you have a multi user database with thousands of records on a server. The recommended approach is to make a copy, compressed if you want to shrink it, or a clone if your data file is very large. You can then try things out in a non critical setting. When all is well import your records into the clone, rename it and make it the active file. (Great system for a single file in one folder with no external relationships or plugins...Appaling for 15 files with 25 relationships and 10 passwords and plugins etc etc.)

Hmmm, avoiding crashes... I'm not sure. This probably belongs in a different forum and more detail would be needed

[eremaut]

About FMP 5.5 (Windows),

Did i miss something here when testing the 5.5 pre-release software?

Where can following items be found?

1. From Jodin: 'a script debugger are making me nearly salivate'

2. From the FM's web: 'the Send Mail script step with mail.app'

3. From Kraftyman: 'script runs on loading a page' & 'direct send mail'

---

Comment on FMP 5.5:

To many bugs for the moment. I've reported several bugs to FM, found in 5.0V3 and 5.5, none of them are fixed today !

Among these bugs is a real killer bug from category 1-Data Loss/System failure. In short, the decimal part of a number is

[scratchmalogicalwax]

I agree filemaker has some bugs....it isn't oracle and it isn't sybase but there is no other database application that can produce solutions as quickly and easily as filemaker for the company I work for.

We produce very complex relational database solutions. Two of which are used to process speculative job applications for two very large multinationals.

They process the applicants CV's by extracting preprogramed skill sets from the text and match them against skill sets relating to positions available in the companies. The results are manifested as a percentage match.

We also use filemaker for online applications and we have found that the ease of use and speed of deployment has made it possible to undercut our competitors (which there are many) with ease with no loss of functionality or quality for the client.

We couldn't buy off the shelf "search and selection" software for the Mac but we could produce it with filemaker......i'm not saying that any other database product couldn't do this i'm just saying it would have taken twice as many people twice as long and to what end........the same one!

I think 5.5 is really for us web developers with the enhancements to the WC. Either way I like filemaker and it's good points far out weigh the bad.

[Moon]

My two cents worth, based on one whole day with 5.5.

Updated for $30 thanks to a purchase late April of FM Developer 5. I mailed the upgrade with check and proof of purchase a week ago today and received my upgrade copy last evening. In spite of the "please allow 6 to 8 weeks for processing" admonition. Nice surprise.

Installation a piece of cake on 9.1 Macintosh. Tried to install the OS X version on my OS X partition, but it could not find an eligible file to upgrade. I will install FMP 5 on the OS X partition and try again.

OS X version docs seem to indicate a bunch of stuff that is not there that is in the Classic version, but I believe they are missing in OS X as it exists. Missing:

ODBC Support

Execute SQL script step

Dial Phone script step

Toolbars

The AppleTalk network protocol for sharing files with Mac OS X

The Send Mail script step with Mac OS X Mail application

So much for any comments on Mac OS X at this time.

I find missing in 5.5 what was very concisely put in Kraftyman's earlier post:

"I long for the day when data can be divorced from the interface, so I don't have to worry about importing/exporting thousands of records, each time I want to change a layout. I salivate over the thought of saving my scripts as a separate entity from the data, and e-mailing them to my friends, so they can import it directly into FMP. I dream of being able to run a query, without having to design 15 layouts in the process. I want to preview the record I just browsed without having to "find all, omit and then show omitted". I want to store variables without having to create global fields which choke ODBC clients..."

I do appreciate the windows for define calcs, etc. having a size memory now, but that should have been done long ago.

I still long for the ability to set custom orders of field definitions and scripts that can be recalled.

The script debugger is NOT in FMP 5.5. It supposedly will be a feature in the 5.5 version of FM Developer.

Interesting new functions which will permit more powerful scripting and management tools for "Devleloper" files (meaning files to help us develop, but not for client consumption).

Seems like a lot of the improvements are for Web enhnancements, which I am unqualified to comment on.

This is brief, as I have hardly shaken out anything yet, but nothing pops out at me thas screams "I gotta get this." I think the upgrade price of 150 is excessive, but I will get my money's worth out of the 30 buck upgrade. My initial observation echoes Kraftyman. A nice update, but an overpriced upgrade. Still an outstanding product.

[Anatoli]

RE: I long for the day when data can be divorced from the interface, so I don't have to worry about importing/exporting thousands of records, each time I want to change a layout.

No one is really forcing you to do this. You can have just database with layouts and database with data. Just link them.

On the other hand, show me another database, which works in heavy duty usage, and I can still program their scripts and layouts "live" through Internet on 64-128k line!

[kraftyman]

quote:

---

Originally posted by Anatoli:

On the other hand, show me another database, which works in heavy duty usage, and I can still program their scripts and layouts "live" through Internet on 64-128k line!

---

I am unqualified to comment on web usage of FMP. All power to them if it is that easy.

quote:

---

Originally posted by Anatoli:

No one is really forcing you to do this. You can have just database with layouts and database with data. Just link them.

---

As a matter of fact I am attempting to do just that. Great minds think alike?

My primary database has about 180 fields, including the jolly globals needed for variables. It is linked to 6 other files which carry related data. I managed to get most of the UI into the main database, so the scripts would work properly. I plan to send off the whole package as a standalone product. The only thing is the searching. The user needs to be able to do complex serches with AND and OR statements, as well as produce

lists. I found that I almost have to create a layout for every type of search ( and include a few more global fields and scripts for each) because FMP will not produce data/reports "on the fly" without adding specific summary fields etc.(unlike MSAccess) My first attempt then ended up with moe than 255 fields. This was a bummer, because now I was unable to pull data out of FMP via Excel.

(Incidentally, for complex searches, it is so much easier to connect to FMP from Excel via MS query and pull data out than to create such searches in FMP itself.)

I cannot write any of this user interface without access to the data structure. Now pulling that out of the server is not so quick.(You know the drill. Get everybody to log off, shut down the server, go to ANOTHER machine with a proper FMP installation, connect to the server, make a clone,restart the server and repeat the process in reverse when you come back after adding some global fields etc etc.) One of the connected files is 1.2Gb in size. (Don't ask, it wasn't me. THAT baby was designed with no less that 40 repeating fields, and has embedded graphics)

Plan B is to create a database just for searching, then I can give FMP all the jolly globals it needs. This one will import/export record Id's on startup, and link the rest. And I should be able to get a bit more freedom with the UI.

As I struggle with this, I realise that in the end I will be able to do what I need to do. FMP has never really failed me before, and it will succeed again. But it could be much better.

[Anatoli]

RE: Originally posted by Anatoli:

On the other hand, show me another database, which works in heavy duty usage, and I can still program their scripts and layouts "live" through Internet on 64-128k line!

------------------------------------------- and

I am unqualified to comment on web usage of FMP. All power to them if it is that easy.

---------------------------------

It is not web usage. I am talking about the easiness of Remote programming; I do not have to travel to clients so often. I am doing the job as I was at client premises and in fact I am at home or main base.

[Anatoli]

RE: One of the connected files is 1.2Gb in size. (Don't ask, it wasn't me. THAT baby was designed with no less that 40 repeating fields, and has embedded graphics)

------------------------------

Better to rework and redesign the beast

[kraftyman]

No disagreements here , but I'm not the boss fella.

[Anatoli]

quote:

---

Originally posted by kraftyman:

No disagreements here

, but I'm not the boss fella.

---

Tell him/her, that he/she is asking for troubles.

And one nice day he/she will get them.

Then he/she will be no boss anymore