Yes FM5 for Windows have limitation

[peterlacenne]

Hi developper,

Just let you know that FM 5 have limitation in the size of your "programming code" (large number of script, define fields, links and layouts).

Here is my story with FM 5 for Windows, i created a solution with 19 files and one of my file have more then 1300 different scripts, more then 180 differents layouts, more then 500 fields and more then 300 links.

The problem is you cannot created a new script or modify an existing one. Plus you get a bonus when you try to print FM crash...

So, be careful of this

P.s im not alone with problem with Windows...

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

Eric Veilleux

www.maerix.com

[fishma]

I believe your limitation may lie with the design. Proper normalization and script creation should move you away from those ghastly numbers. Thanks for the info though...

Fishma!

[peterlacenne]

You should see what we have done and by the way it is working very well with a Mac so in term of design hum

;-)

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

Eric Veilleux

www.maerix.com

[fishma]

I would love to see the specifications on the application that you have created. I apologize if I came off a bit condecending. In my experience, I have never ran across the need for so many different scripts and so many different layouts. I am curious to see the specs and requirements. So if you have the time. I'm always interested in learning something new.

Fishma.

[Kurt Knippel]

quote:

---

Originally posted by fishma:

I would love to see the specifications on the application that you have created. I apologize if I came off a bit condecending. In my experience, I have never ran across the need for so many different scripts and so many different layouts.

---

I gotta agree with Fishma here. Generally when you end up with that many fields, scripts or layouts, it is a matter of poor design or you are simply try to do much in one file.

I am sure that you all of that stuff is needed in that one file and could be broken up into many smaller files. This make programming a bit more difficult, but performance, security and maintainance will be much easier.

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

=-=-=-=-=-=-=-=-=-=-=-=-=

Kurt Knippel

Consultant

Database Resources

mailto:[email protected]

http://www.database-resources.com

=-=-=-=-=-=-=-=-=-=-=-=-=

[peterlacenne]

Sorry guys but you really don't know what you are talking about.

I dont have only one file to do the job in fact i have 14 differents files, so is it enough for you or should i split them in the max 50 differents file.

What i want to bring here is fmp is not suppose to have limitations in scripts, fields definitions, links, layouts, etc.. but in fact, there are limitations no matter how you design your solution.

[yafreax]

you know, he's got a little wink up there as his icon in the last post but i think he's probably actually frustrated. Kind of like Vaughan's first day when i told him he had a little too much time on his hands :

http://www.fmforums.com/ubb/Forum1/HTML/000006.html

well, i better throw in my two "sense" here so as not to waste your time. . .

I've seen some crazy things in my short life (i'm probably younger than any other member, that's where i get my smart alec attitude) but none as crazy as when i read the first post. . . however in your defense,I have a solution or two that seemingly continues to grow larger and larger everyday. None to the extent of yours. . . it's not that we don't believe you, it's just that it's a very unusual size. I think that we are all pretty curious as to why you would need this kind of fire-power. Unfortunately we "developers" like to share hints and tricks, but not solutions. . .

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

Filemaker's kind of like a wife; easy to love, yet just so complicated.

[peterlacenne]

Im not frustrated at all , my first posting was to share a hint for all of "developers" because i am not alone to reach this "limitation" you can look in the fmforums and you will see.

Second i dont agree with you when you say that is not a "normal" file size. FMP is not only a tool for small solutions you can created something very professionel for every database need in industries.

Just look at the FMP list of customers.

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

Eric Veilleux

www.maerix.com

[Kurt Knippel]

quote:

---

Originally posted by Maerix:

Sorry guys but you really don't know what you are talking about.

I dont have only one file to do the job in fact i have 14 differents files, so is it enough for you or should i split them in the max 50 differents file.

What i want to bring here is fmp is not suppose to have limitations in scripts, fields definitions, links, layouts, etc.. but in fact, there are limitations no matter how you design your solution.

---

Well my customers and peer tend to think that I do know what I am talking about.

I am not saying that you do not have enough files in your solution. I am simply addressing your one example file. Good design would generally result in a much smaller file in terms of the various resources (layouts, scripts, fields, etc.).

Purely by the numbers posted, I think that you are trying to do too much in that file and it could be broken up into one or more additional files in order to lessen the load on it.

You have up to 50 files to work with, do not be afraid to use them.

There are of course limitations to the amount of resources in any thing. FMP does not have any particular limitation to the number of layouts, fields, scripts, etc. But every single one of those takes up some amount of resources and eventually those resources will be used up. I am sure that FMP could spend time and effort in determining the actual maximums, but it is probable not worth it.

It is hard to look at your own solution and see the flaws. Show it to a trusted peer, and perhaps they can point out some way to optimize or break up the file for better performance.

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

=-=-=-=-=-=-=-=-=-=-=-=-=

Kurt Knippel

Consultant

Database Resources

mailto:[email protected]

http://www.database-resources.com

=-=-=-=-=-=-=-=-=-=-=-=-=

[Arrogate]

OK, OK, go easy on the guy...

You guys should come take a look at the FM insanity we have here. Even the people at FM itself don't believe we are doing what we're doing. (We've had techs and reps here that just stare in disbelief) We have a 17 database system with one that has reached the limits and has been split a couple times. But every time it is split, it is just more headaches, not increased stablity, or whatever else is supposed to come of splitting. And every single layout and script is absolutely necessary. And there's a team of 8 people working on it, so there goes the fresh opinion...

I'm not trying to brag or put anyone down or anything, but just to say that it is VERY possible to reach the limits of a FM system. That's why the world has Oracle and things like that. But we don't love Oracle. We love FileMaker. So we make it work...

[peterlacenne]

Thank You, thank you, and thank you again...,

What a good answer to explain something as simple as reach the limit of FMP.

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

Eric Veilleux

www.maerix.com

[fishma]

I have to add my support to the Captain.

The first thing you do after the design of a database solution, is to determine if the solution is scalable. That is, will the design handle large numbers of records and will the design allow for the addition of new requirements at a future date and time. If the design is modular and normalized correctly, with the fore-knowledge that new requirements will come to light, that answer should be yes.

With the numbers you are reaching, my interest is piqued as to how why you reached those numbers. If I was brought onto your team, my first inclination would be to re-design the system. The biggest problem with development, is time and the lack there of it. Systems often get developed without proper design in mind, and poorly designed solutions are made in haste. These systems become the staple of a department. When new requirements come up they are forced onto a poorly designed solution. That SQUARE peg is forced into a ROUND hole. Instead of layout re-design, layouts are hastily added. Instead of script redesign, new scripts are written. Instead of creating better field definitions, new fields are added. The problem grows even larger. People, and especially programmers, are fiercely loyal to legacy systems. They tend to shy away from re-design due to time constraints, re-training issues, and the admission that there could be a better way to design the solution (they would have to admit thay thay be fallible). Considerations often overlooked.

I'm not saying that you do not need everything inclusive in your design, or that your design is poorly made. But in most cases where legacy systems are involved, in my experience, a re-design is necessary. Not in your case though.

I appreciate your tidbits of information on the limitations of FMP. The information will make me sound smarter in my next design meeting. God knows I could use it. But for me and my design philosophy, those numbers are nothing but trivial facts.

I hope I have not offended anyone with this post. It is not my intention. I'm just trying to get everybody to think outside their own design philosophies, and consider how they themselves, myself included, can become better programmers. We are a unique breed of solution providers. The better we are as a whole, the better we look to prospective Clients. That keeps bread on my table...

Fishma.

[peterlacenne]

Well, maybe you are right in terms of design for our own database but nobody told us that FM have limitations. In fact, the design we have made is something that i never seen before even with the more powerful database comercial systems like SAP, BAAN, JD, etc...

So, in my mind is like with FM you can built a skyscraper but you can only use the few floors... even if i have the best skyscraper design....

What do you think

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

Eric Veilleux

www.maerix.com

[Kurt Knippel]

quote:

---

Originally posted by Maerix:

Well, maybe you are right in terms of design for our own database but nobody told us that FM have limitations. In fact, the design we have made is something that i never seen before even with the more powerful database comercial systems like SAP, BAAN, JD, etc...

So, in my mind is like with FM you can built a skyscraper but you can only use the few floors... even if i have the best skyscraper design....

---

EVERYBODY has limitations. Everybody will run out of resources eventually.

Filemaker has chosen a path of increased flexability and user features, rather than the more spartan RDBMS that you mention.

FMP has also chosen to go with an all-in-one development/server/client paradigm, rather than the seperate packages that other systems use. This has both good and bad points.

Deploying FMP, even with a heavily customized solution, can cost as little as $250 per seat, from 1 to n seats. Any SAP of BANN solution will run you upwards of $2500 per seat.

Again, I am not saying that you did anything wrong. I have never run into the situation you describe, but I cringe when I see a solution with 400 or more fields. I actively try and reduce the numbers.

I came from a background of programming in Basic/Pascal/C and I always remember something that one of my professors taught me: If you have more than 20 line in any routine or 20 fields in any table, you have too many and you need to break it up. I really strive for this and actively review my solutions for way to accomplish this.

**Now of course with FMP, which includes variables, calculations and summaries as fields, I have databases with potentially 100s of fields, but I still try to keep the actual data elements low, as well as all the other fields**

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

=-=-=-=-=-=-=-=-=-=-=-=-=

Kurt Knippel

Consultant

Database Resources

mailto:[email protected]

http://www.database-resources.com

=-=-=-=-=-=-=-=-=-=-=-=-=

[airbaal]

I gotta agree with Maerix and his complaints about this one. And it's not just because I've been going back and forth with him trying to get both of our projects from crashing. I think FileMaker has SOMETHING wrong with it: not sure what, but something. FileMaker told him his FileMaker files were corrupt. If that were the case, one would assume the database files would not matter if they were run on a PC or a Mac. Well, him & I experienced problems ONLY on a PC. Ran PERFECTLY on a Mac. So there has to be something to that.

As far as limitations, it really sounds like there are some to it. Granted, if you are an experienced FMaker user, you can easily get around them by breaking files up, etc. I don't know about you guys, but I first started using FileMaker building my project. And I've grown and learned about it as the popularity of my solution has grown, causing me to add to it. Unfortunately, rewriting and splitting up my project is not as easy as copying and pasting code to another file, unless somebody has a way to copy fields & layouts easily. For people like us who started learning & writing databases at the same time, we are in an unfortunate position.

I am going to start a rewrite of one of my apps down the line, and unfortunately, FileMaker is not going to be used. I am playing around with Visual Basic, ActiveX Direct Objects, and Microsoft's Jet engine (access files). I love the speed of development in FMaker, but you lose raw power. The unability to run a script when you leave a field, tabbing to buttons, customized shortcut keys (besides leaving stuff in Scripts), inability to really communicate with other Windows programs, and the poor method of upgrading multiple databases at once is a big turnoff when you are trying to sell a "professional" package. It's funny, FileMaker has been around forever. You would think they would address a few of these issues.

My frustrated $.02. :-)

Eric

[Anatoli]

quote:

---

... For people like us who started learning & writing databases at the same time, we are in an unfortunate position.

I am going to start a rewrite of one of my apps down the line, and unfortunately, FileMaker is not going to be used. I am playing around with Visual Basic, ActiveX Direct Objects, and Microsoft's Jet engine (access files)...

---

Rest in peace... my 2 cents...