rcassidy

I use PNGs in my 7 solution and have a technique that works very well. If you want tabs that can expand horizontally well, create a left and a right version of the tab. Each should be rather wide - more than 1/2 the width of the widest tab you expect to make and the right edge of the left tab should transition well to the left edge of the right tab. Make sure you set the transparent channel of the PNGs. In FM, set the left version to crop/align left, and the right version to crop/align right. Put the two next to each other so they appear as a complete tab and group them. You can now resize the image to exactly what you want and won't get any stretching. The transparency will let you put them anywhere without much concern. If you put a text label on top - centered - when you group, you can just edit that and it'll size as well. Makes creating tabs very, very fast. You can also stuff the graphics into a global container and do the same thing - the advantage is that it then shifts from layout to data, and you only have one copy of the graphics to deal with. If you put your tab labels in a global repeating then the whole thing is very easily edited or made dynamic.

Well, I came here looking for some advice on my solution. I've taken a slightly more than 100 table FM 6 solution and am reworking it in 7. I opted to separate data and interface and have multiple data files and multiple interface files. Data is separated primarily by user authorization - I download data from multiple sources, each of which has specific access requirements, so a file for each source (up to 60 tables per file - the table limitations have allowed me to set up the data more naturally than before) and I generate data which go into a file for each data category. Right now there are 5 data files, and there will be 8 when done. I have different types of users accessing the data - some are primarily clients of the data - they view, search - others are maintainers of the data - they do entry, generate reports. There is an interface file for each type of user. In the end, there will be about 10 interface files - some for fairly specific activities, others very broad. So far, it seems to work quite well mixing/matching data and interface files, and has helped to keep the interface more focused on specific tasks rather than focused on a specific data set. I too will use external authentication to manage users and passwords. (Releasing FM Server Advanced now would be very handy...) I'm getting somewhat concerned about my primary interface file. The interface file just crept over 150 relationships and at the current pace will close in on 300 when done. Technically it can be done, but I'm not sure if it's wise. I can divide the file logically, but I lose the benefit of a certain amount of code and relationship reuse - I'll wind up with roughly 2 200 relationship files, and a ton of script duplication, which might be manageable with some extremely careful development to minimize cleanup of imported scripts from one file to the other. Of course, everything in one place would be ideal - if a bit difficult to manage. So, my question is, has anyone really pushed the relationship count that far? I'll point out that very deep relationship chains do bog FM down. I have a few occasions for 15 table deep chains on display, and they're pretty sluggish. Once things are working, I may have to go back and rethink some of these simply for performance reasons.

I agree that there must be something going on with FM7 import. The progressive slowdown is likely a memory bug that FM has yet to track down. Here's a few other data points from my recent experience: Lookups and autoenter calcs that follow a relationship are devastating to performance - even when all fields are indexed. For example, I need to lookup two fields upon import from one table to another. Import without the lookup takes about 4 minutes (162,000 records, about 16MB). Import with the lookup takes about 4 hours. Now, this is a straight field pull from an *indexed* field. It's no more complex than grabbing the related data for a portal, other than it needs to get written back out to the table. Next, I did a straight import - no lookup, but ran the lookup as a separate step. Same thing - 4 minutes for the import, 4 hours for the lookup. Next, I tried doing two imports. The first was the straight import as before - 4 minutes. Then a second import from the tab-delimited file that I populate the related table with, doing 2 field matches on import. So this second import needs to match data against 2 indexed fields and import the two fields that I was previously looking up. This only took 9 minutes. Now, this suggests a pretty serious bug in FM. There is no way that a field match from a tab delimited file should be faster than a indexed field to indexed field lookup. The latter, in fact, should be substantially faster. Now, I've found a viable and not too onerous solution to my situation, but I can see plenty of situations that don't lend themselves to this kind of work-around. I have another suspicion that I have yet to test, but will - that lookups across FM7 *files* may be faster than across tables in the same file. I can see a possibility that the performance problem is some kind of odd file locking problem. I'll test that in the next day or two.