Title says it all. It's okay to set aside your humility for a moment here.
Title says it all. It's okay to set aside your humility for a moment here.
Any or all of the above. Complexity, size, users, locations.....just anything BIG.
The one I work in nearly every day....
Only about 30-35 users daily but it has
77 Base Tables
1940 fields
226,638 Records
239 Table Occurrences
215 Relationships
58 Accounts
209 Layouts
421 Scripts
127 Value Lists
23 Custom Functions
I haven't made many monsters but I've made one or two dogs.
well I am not even close to achieving the developer title, but given the circumstances of starting on this project and not knowing anything about FMP, this is my one and only. Though given the small size and limited tools ( IT limitations) I have learned a tremendous amount and mainly through this community. So thank you all
Can't offer any monsters but trusted companions. I ran a solution for over seven years that managed and analysed delivery documentation and created airworthiness certificates. This was crucial for keeping the supply chain up for delivery to a major commercial aircraft OEM. Shipping late or delivering with non-conformities creates mayhem.
The solution was operational for more than 2600 days in a row, with only a single working day of unscheduled downtime due to a grilled hard disk.
In this picture, 'big' is synonymic to 'very reliable'.
That sort of reliability in a solution for that many years is a marvelous feat, Torsten. Especially when you look at all the things a person has to anticipate to make a truly reliable app. PhilModJunk has talked about this subject a few times ... how an experienced app builder will look at things carefully and identify potential fracture points. In my short time doing this, I'm realizing the full wisdom of using that approach.
And another layer: seeing how employees ACTUALLY use an app in an organization. Sometimes it really differs from what a boss envisions. You know, the whole difference from seeing things from a soaring visionary perspective vs. how stuff actually happens. No matter how much you stress training, there are business environments where it doesn't exist. You gotta make something super accessible and totally unambiguous, so you don't have something you made for Purpose A being used for Purpose Z.
And another layer: seeing how employees ACTUALLY use an app in an organization. Sometimes it really differs from what a boss envisions. You know, the whole difference from seeing things from a soaring visionary perspective vs. how stuff actually happens.
I think this is a HUGE factor and great point. to elaborate a little more in my situation. We have an two staff members titled as "Database Programmers". They initially, set up a DB for our group but do not have an understanding of day-to-day operations (they are "IT" and we are science nerds). This left many data "holes" and end user frustrations due to design (most of the tables did not utilize keys). another example is that they couldn't didnt understand that a sample could have more than one result. So if a sample result was questionable, we retest it. In their process they looked for the most "recent" excel file and enter a single value by hand, back into the DB. This idea also applied to accounting side where the services rendered had an error rate of ~23%.
Because of 2-3 years worth of negative experience w FMP, and lack of compliance/understanding from the the devs. I was tasked by their supervisors to expand and improve, and even left the door open to total replacement. The main advantage was that I know the flow of data without group, as well as had access to individuals perception of things. I also, started fresh without old habits. End result is a working solution that is now preferred over the old because it makes "sense" to them. Of course it prob is not to standards (given it is not my field), but relative to what we had it is a huge improvement and there is pressure to retire their DB, and acquire a FMS install that i can control.
Whenever I develop on my laptop machine, it's guaranteed that a monster is involved.
As far as big, I don't create them, but I have been called to work on some. Widest table, IIRC, was around 2500+ fields. There's often a silver lining, though, and it's usually been about how my FMP game improves in some way or another in order to meet the situation...
We have developed some very HELPFUL and POWERFUL solutions for those who would normally not be able to afford the time and cost of traditional custom development at the individual, non profit and enterprise levels.
Really looking to expand these applications to see if we can make FileMaker the preferred platform for iOS Mobile development. Let's go!
Thanks for the question BuzzardJunction. Since I have no other databases made by others to compare with, the answers in this thread are very helpful to me.
The database that I am working on at present has about 40 tables, but over 1700 relationships. The former, I don't consider big, but about the latter I am sometimes wondering how good or bad this is. The bulk of the relationships are mostly designed to create user-level control over how a field behaves in terms of value-lists and value control, export settings etc. Those fields whom it concerns, each have between one and four relationships and four to five support fields to make them work. It creates a high flexibility for the user, which is what I was after.
For sure, the thing runs, with just a handful of users and the main table having 7000 records. I have never had to put it through high-speed or calculation-intensive use since it's main function is to assemble data and export it to flat tables that are then processed in spreadsheet or statistical software.
The interface through webdirect is a bit sluggish at times but I am not sure to which extent that is due to the design. The wifi connections (which the users use) to the server has a varying quality, the server is used by others and its backup-scheme seems insane to me (every 15 mins.) which makes me guess that the machine is often busy with the overhead.
I never realized the full extent of how different the development times were until I spoke to a programmer who's in charge of about a dozen other programmers.
I showed him an app I made in Filemaker and asked how long it would take his team to replicate it. I come from a completely unrelated field, so I was curious to find out. His rough estimate was EXACTLY the same amount of time I'd spent building it in FM......by myself.
Over 800 TOs was my record. That was in FileMaker 7. Would only need maybe half the TOs in Filemaker 17 if I built it again.
1300 scripts
Using Separation Model, so got Data file and GUI files for different departments/purposes
Not my largest but one of the big ones I am working on right now.
Tables: 142
TOs: 1691
Fields: 9128
Relationships: 1530
Scripts: 1789
Script Steps 57,110
Layouts: 904
In terms of record counts one of my other systems has over 32 million records in one table, over 100 million records total.
In terms of file size one of our largest databases, that is mostly text is tipping 1TB when I looked at it last year.
In terms of age of systems, our oldest is 22 years old now.
These are all systems in production some are used by 25 users others are used by over 350.
Hi All,
I think, In the Monster who feel like didn't even touched the "M" too! Because here below mine as same like badmonkey842 said with lot of IT limitation!!
Tables : 150+
Fields : 1850+
Relationships : 60+
Scripts : 225+
Layouts : 155+
Script Steps : 1120+ (without comments)
- Suresh
Don't know if this qualifies as a "monster", but it's the largest I've worked on.
Confirmed. There is always a delta between plan and execution. One of the biggest challenges for reliability is regression.
I have spent a fair amount of time testing for regression on OS, FM and application.
Regressions that do not receive a fix effectively block the upgrade path.
I'm just curious, but how does one interact with 1589 layouts?
No software I have used seems to even come close to that number of layouts.
How many of those are reports? How many of those layouts are used regularly?
If i'm a clerk and my job requires working in even 100 different layouts regularly, that already seems like a lot.
I think I would need to see it to grasp why all these layouts are really needed.
I can't imagine that there are that many layouts that need to be worked with.
I imagine that many of those layouts are utility layouts and not actual user interface layouts. E.x. i have mine project set up so that there are script layouts that usually contain zero fields, I have report layouts, End User Layouts, and a few data admin layouts. If you factor in different screensize resolutions, mobile devices, printed reports, etc... it can really increase those numbers.
though, i could be wrong in my methods / reasoniing
A large number of the layouts are maintenance layouts. I routinely have two maintenance layouts for every table, one with no fields and one with all the fields (minus things like global fields and summary fields). The blank layouts are used for scripting. That way, if something unanticipated blows up a script and leaves the user looking at a maintenance screen, it doesn't create temptation to do things like manually changing data outside of the scripted process. The ones with fields are used for admin maintenance.
As for the rest, many of them are reports or user dialogs. So the vast majority of the layouts are not user data entry screens.
And this may be total layouts (many files/databases). Sometimes there are layouts that are not often used, but still needed. Sometimes the client needs "just one more report and just so". I work with these kinds of many layouts where we now can search and narrow which layouts to show in the "list" (Layout Mode). So I learned early to NAME these layouts well. having folders is also a blessing, but I try to still name the layouts uniquely, but logically.
Beverly
Yes, that’s right, Bev. This particular app is a six-file system, so the totals include all the files.
I'm in the process of rebuilding this:
into something with:
This isn't my largest, but it's pretty big...
~Linda Carter
www.compu-books.com
Biggest in what sense? Most tables? Most records? Most relationships? Most files? Most users? Most locations?