ckai

You're a champ mate! Changing the theme opens up the other options. I suppose that means I'm finally going to have to get around to creating a custom theme. Thanks heaps. That was doing my head in!

I was just wondering if anyone had any ideas why this would be happening. I've been working on a database that was originally created in FM 11 but has been converted to work with FM 14. I went to format a checkbox set the other day, and I don't have any of the additional options that are standard for FM 14 (see screenshots). I ended up creating the style I wanted in a FM14 database then copying it to the converted one. A bit of a bugger and a little time consuming. I'm assuming it's due to the conversion since I can't think of anything else. It's been converted for a while (nearly a year) and running fine, but I'm wondering what else could be missing. Does anyone have any explanation or ideas of fixing? Thanks

I have the same problem and Scriptmaster is the only plugin that this is bringing the message up. The real problem I'm having, and have had always with Java 6, is that it brings up a "exec" icon on my dock that is "not responding" and means I can't shut down the computer without force quitting it first. Force quitting under normal circumstances just pops it back on the dock straight away. So for all this time I've removed Java 6 but I believe Java 7 isn't compatible with Yosemite and Scriptmaster doesn't seem to like Java 8 (since the message appears even with Java 8 installed). I've tried fixing the issues with Java 6 but can't seem. The only thing that actually worked consistently was removing it. It looks like I may have to go through my database and see what scripts use Scriptmaster and see if I can figure out any work arounds so I don't need it. Java 6 is that annoying for me, which is a shame.

A few of the portals have sorts and filters on the display side. A few have sorts through the relationship. I just noticed one portal is sorted through the relationship and the portal itself. I think I was a bit eager getting it how I wanted! One portal has a fairly decent calculation for a filter. It's used to display notes for clients. It no client selected it shows all clients notes, if a client gets selected it shows just those notes. You use the side navigation to select the staff member, that shows shifts worked for the staff member. You can then select a client to show notes for that client and all shifts for that client during the period. There are a few summary fields in 2 other portals that I actually missed counting since they're essentially hidden. I know they can slow things down as well but overall, this layout is pretty much a simpler version of my existing layouts they don't show the lag. Are you saying it might not be the Set Field script step that's slowing things down and the actually display of the portals? I might do the old test of removing portals to see what makes a difference. Actually, I may remove all the portals apart from the staff navigation list and show just the global staff ID field and see how quickly it gets updated. That will certainly narrow down that issue. I will have to revisit the setups of my portals. I think I am a little lazy when it comes to sorting and filtering.

 No unstored calcs based off it. But you make a good point that overlooked with regarding Filemaker having to recalculate them. I do use a lot of unstored calcs in other tables and it's something I'll keep in mind for the future. It would have certainly explained the slowness if it was the case. All it is, is a simple global staff ID, which is linked to the staff ID for 2 other tables.  The relationship, at least to me, isn't complicated at all. I do have 2 tables based off the one global field but it's certainly nothing I haven't done already. My navigation list of staff members is based on a cartesian join to show all the staff members and the other table is a relationship shown in the attached screen shot. There's only one calculation in that relationship (flag_WageShiftCount) but it's indexed.  Definitely not multiple windows open. I create new hidden windows to perform complex scripts but they never stay open past the end of the script, and none are created when using this particular layout.  I might have to do some tests in using a self join table based on the staff members as opposed to the global table. But that just doesn't make sense to me. I can't see how using Set Field would be faster on a self join table compared with a separate table.  When using Script Debugger, once it has updated the global field the portals update straight away. Your suggestion of an unstored calc has got me thinking that somewhere, something is updating. I just can't think of what if it's not unstored.  I shall do some more digging. Cheers.  PS You are skier or boarder?Â

I'm just wanting to know if anyone has some suggestions as to way one particular layout would be updating slower than the others that are designed in a similar way. The layout is pretty much only portals. 4 of them in fact. One is a navigation bar down the side (staff members), the other 3 display the relevant data from the selected staff member. Only 1 of these portals is used to enter new records. The layout is based on my global table. Selecting a staff member updates, via script, the global staff id which the other portals are linked to by relationship (and other criteria). The majority of the time, selecting a staff member for the navigation portal is pretty slow. I'm talking a couple of seconds. Debugging it seems to show that it's the Set Field step that is slowing everything down. Which I just don't get. I use this navigation method throughout the whole database and the set field is pretty much instant. And the other layouts use more portals. The only big differences I can see between this layout and the others is this one is based on the global table and the others are based on self-joins. Would this slow is down that much? This isn't really a "fix my database" question, it's more of a "what type of things can slow the layout down in this situation" discussion. Basically, I'm trying to avoid possibly doing anything detrimental in the future. I am using the Refresh Window script step but not flushing cache. Normally I'd use Cartesian Join relationship to refresh the portals but I need the ability to create new records in the one particular portal. I just find it quite interesting how performance can change dramatically based on a similar layout structure. I'm all ears

Maybe I was a little to hasty. The problem I have now is I can't get the total hours calculation in the staff table to incorporate two date fields - Cancelled and Transferred. Both of these fields need to be empty to be included in the wages but I can't seem to work out how to allow for empty values to be included in a relationship. I tried creating a calculation that converted the empty values to 1 then including this in a relationship by using a constant one global field but that didn't work. The total hours calculation returns nothing. I thinking I'm over thinking EDIT AGAIN: Yip I was over thinking it. Instead of trying to create a relationship with the Cancelled and Transferred date fields, I ended up creating another calculation in the Shifts table that showed the hrs figure only if Cancelled and Transferred was empty. I then just totalled this new field instead of the normal hrs field. Easy once I stopped thinking

It gave me a headache as well! Thanks heaps for the example. I'm still digging around with it trying to figure out how it works, looking closly at the "Staff for filterered shifts" portal. That's exactly what I'm looking for my staff list but need it based on the "all shifts" portal as opposed to the "shifts filtered for client portal". So I'm digging around to see how you achieved it. Regarding the date filtering, yip got that all ready to go just waiting for my brain to work... any day now haha. I was going to do the date filtering from a portal filter but I realised that was stupid when I was applying the same criteria to 3 portals. Much better to use relationships for that. EDIT: I think I've worked it out. I was wondering what the TO "control_Shifts_forStaffforShiftsbyClientAndDate" was for because I couldn't see how it related to filtering any of the portals. Then I noticed you used it to calculate the total hours worked. That's simple and clever. I was trying to group the shift results for the list as opposed to just using the staff table I already had and filter based on a relationship/portal filter. Now to work out how best to incorporate the other factors into the the calculation such as shift cancelled date. Would not have worked this out without your example. Very much appreciated.

Thanks, although I've been looking at this and trying to work out exactly what you mean. You're meaning the relationship would look like this: staff --> shifts --> client_SHIFTS ? My idea for the relationships was this: globals --> staff_SHIFTS (shift table with predicate is gStaffID = _kstaffID) - takes care of the staff shifts --> client_SHIFTS (shift table with predicate is gClientID = _kclientID) - takes care of the client shifts plus, of course whatever relationships to get the staff list showing. The entire layout would be based on the global table. That was the idea at least. This is probably why I can't quite get my head around your suggestion.

Well that title wouldn't help much! haha I'll try and explain this with exactly what I'm aiming to do. I'm trying to create a layout for when I do our wages. The plan is to have 3 portals: 1. staff_LIST: a list of all the staff members that have completed work for clients within the wage period 2. staff_SHIFTS: a list of all the work (shifts) the selected staff member (from staff_LIST) has done within the wage period 3. client_SHIFTS: a list of all the work done for the client within the period which is selected from the staff_SHIFTS portal. All these portals would be based on a table called Shifts - it contains all the work done for each client. Kind of like a line items table for invoicing. What I planned on doing was have 2 global fields in my global table gStaffID and gClientID. Both the SHIFTS portals will be based on this field. The fields get populated by a "set field" calculation when selecting the particular portal row. This I'm cool with. I've done is throughout the database. The problem is the staff_LIST portal. I can't work out, for the life of me, how to only show 1 instance of each staff member only. My idea was to filter this portal for the time period then work out a way to only show each staff member once. I've tried all sorts. I've tried to work out a relationship to only show the unique records. I've tried filtering based on an unstored calculation that only shows the staff id if it hasn't appeared previously. This is maybe an issue since the calculation is reliant on the sort order. I'm thinking a relationship is the way to go, but just can't get my head around it. I've searched a massive amount but still at a lose. I'm more than likely over thinking things. Any fresh ideas would be a great help. All criticism welcomed It's annoying because I'm basically trying to show all the information I need on one layout. Currently I have my staff list is on a pop up window, which opens the staff shifts in the main window and I have to leave the layout if I want to check all the client shifts. I populate my staff list currently by doing a find on the shifts for the required period and use a subsummary layout.

Wow, that's KISS at it's best! It actually took me a bit to get my head around it since clearly I was over thinking things. To be honest, I feel like a bit of a muppet after seeing this now. I use a similar technique to create our staff wage export file but didn't think of using a calculation to do the sorting (dunno why not). I've worked out an interesting calculation that takes all my criteria into consideration and with a little bit more tinkering will be perfect. How many times do you shack your head when people over complicate things? haha Thanks again.

Exactly, this was one of the reasons why I was trying to think of another example. Basically, this is only one part of all the records to be exported and are the only ones that need grouping. The other records can be exported as they are without grouping. Funder clients get grouped Facility clients don't Hence my logic behind a temp table so the records, grouped and not, get exported in one hit, in the same single file. This single export file contains both Funder and Facility clients. My examples only based on Funder clients since that's where I'm having the issue. Never mind. I'll eventually crack the sucker! Appreciate your time. :hairy:

I've been trying an idea for the past 2 days hence my lack of response. For some reason I can't edit the original post, and unfortunately I can't really make the example any easier to understand (tried to - I think I'm stuck in my ideas thought ). But hopefully to make things easier I thought I'd really simplify things: So this is the data that needs to be worked with: Client Staff Hours Total Date Client 1 Jones 2 hours $20 1/7/12 Client 1 Jones 3 hours $30 2/7/12 Client 1 Jones 1 hours $10 7/7/12 I want is to look like this when it gets added to the temp table (for exporting): Client Staff Hours Total Date Client 1 Jones 6 hours $60 1/7/12 So since the 3 original records have the same client and staff, they get grouped into one entry with the hours and total added together. The date is irrelevant so it just uses the first. What I've thought of doing is within my loop, if the client and staff matches the previous record, add the hours and total to a variable then move on to the next record. If they don't match, the variables get added to the temp table. I've got it to partly work but, using the simplified example, it's grouping everything for client 1 even if the staff member is changing. In my real data, I actually have a number of criteria that needs to match not just the 2 for the example but I thought it would just create a lot more confusion. It would more than likely be easier to post an example but I'm unable to do so. I know my loop structure isn't up to scratch, so I'm just chipping away at it to sort it out. I've certainly come to the conclusion this can only be done in filemaker.

I thought of doing the grouping at export but I don't want every record grouped, only the clients that require them. This is the same reason for not grouping the filemaker created xml file using a XSLT, I only want selecte clients grouping. Sorry, when I was trying to remember everything I thought would be needed I forgot to put some headings. I've edited my original post to include them. Poor choice of names actually as I should have kept continuity and used staff 1 etc instead of names. I also see it displays a bit jumbled up unfortunately. Hopefully it's still understandable. No, the database knows which ones get summarized. They're known as Funder (there is a field in the clients table called client_type) and all their records to be invoiced are added to the temp table via a separate script (fun_invoice). I could do one export for non-summarized invoices then another for the summarized ones but each time the xml file is created it will, of course, overwrite the previous one. Meaning we would have to export, complete those invoices, go back to FM, export again, and complete those invoices. A little counter-intuitive so I've gone against this idea. I thought about a calculated summary. Couldn't quite get my head around how I could work it out though. The way I see it is during the fun_invoice script I would "group" the records (as this script works with only Funder records), maybe storing this information in variables, then add them to the temp table. I'm thinking a loop script that checks if the previous record matches (based on criteria). If so, adds it to the variable, if not, the variable gets added to the temp table. As for the version of FM, does it not show on the left side? I'll have a look at that. It's 11 anyway.

I thought of several ways I could do this but always come up with snags. I couldn't even think of an accurate title that explains exactly what I'm after (maybe why I haven't been able to find anything through searching). Hopefully those higher up on the food chain can give me some direction In short, I'm looking to combine or group certain records that get exported to our invoicing software. We do this in the invoicing software manually but thought I'd attempt to cut out the middle man. What happens for this invoice export is I loop through records, storing the relavant data in variables, then add these records to a temp table that is formatted in a better way for exporting. I could possible do it without the temp table but it was one of the first things I developed with the limited knowledge I had. And it works fine which is the main thing. Anyway, certain client gets a more "summarized" invoice than the others. An example of the data Client Staff Hours Total Date Client 1 Jones 2 hours $20 1/7/12 Client 1 Jones 3 hours $30 2/7/12 Client 2 Frank 2 hours $20 1/7/12 Client 1 Fred 3 hours $20 3/7/12 Client 1 Jones 1 hours $10 7/7/12 What I'd like to get put into the temp table instead is something like this: Client 1 Jones 6 hours $60 1/7/12 Client 2 Frank 2 hours $20 1/7/12 Client 1 Fred 3 hours $20 3/7/12 The dates for these clients are actually irrelevant as a date range is added to the invoice. Of course the grouping doesn't need to happen when I add the record to the table. I could add all the records then perform another script to find the required clients, group them in some way, then delete the records that are then not needed. I just thought getting the records into the table the right way would be the best. The export is xml and I thought of grouping the records using a stylesheet. The problem is that the grouping would occur across all the records for every client which I wouldn't want so it seems doing it with FM is the way to go. Any ideas/directions would great. My problem is that I'm unsure how to combine all the required records together into the right variables so they can be added to the temp table. Thanks