Jump to content

daveinc

Members
  • Content Count

    48
  • Joined

  • Last visited

Community Reputation

0 Neutral

About daveinc

  • Rank
    novice
  1. Yes. That does not help. I'm even committing the parent record just for good measure.
  2. Wim, I understand the transactional model, and in fact I am using it in this script repeatedly, but again that is not the question I am seeking an answer to. Because of the nature of our parts list, I have to create the initial Base Estimate Line Item records in their native table. The issue is NOT that my transactional edits after all of the records for the multilevel estimate are created are failing at any level. The script in question creates the initial Base Estimate Line Items and all of the initial Tiered Estimate line items based on the user's selection of a Part made up of many materials and work centers. After the initial Base Estimate line items are created in the Line Items table, my script uses relational transactions to create all of the initial Tiered Estimate Line Items. It successfully completes all of these creation transactions, but misses the first record in the relationship and throws no error because as far as FM is concerned at that point the first related record DOES NOT EXIST. I compared the number of related records for the Tiered Estimates at the end of the script with the number of records in the Base Estimate and it is always the same without any errors(but there is one less record in the Tiered Estimates in reality). I added a Perform Script at the end of the creation script just to compare the number of records a second time from a different layout with the same underlying table, and the second script sees the discrepancy. Why would only the first record in the relationship be the only one that isn't seen(until after the script finishes and I switch layouts, where all is well), and ONLY when a certain script is used, and it never once happened through 12,000 previous estimates created with the exact same procedure/tables/relationships in FM11? And why would a .01 second pause after the initial record creation but before I use the relational transactions to create the tiered records eliminate the problem entirely( admittedly only so far on 100 estimates or so)? You have to remember that this problem is there when there are NO other users connected to the server after hours and can be reproduced consistently every single time. If I run the script in the old FM11 system from 1 month ago(which has around 200 fewer estimates) I can't make it happen even once, and it never happened during the 12,000 estimates made in 11 with all the users connected. The transactional model is obviously the best method, especially for updating the existing tiered estimate records, but I would like to know why a very recently created related record is not seen immediately by FM12 when it clearly is by FM11. This makes me question using relationships for anything where it is important that the script knows what is there when the related record was created in its native table earlier in the same script. Seems I would have to do a lot of extra layout switching or pausing to make sure if I can't rely on FM12 relationships to do this work.
  3. Hi Wim, These triggers are all within the estimate and the estimate can only be edited by the Owner. The Estimate MUST update all of the iterations if there is a change to any one of tens of fields that affect price in the Base Estimate. Otherwise our estimators would be spending their entire day creating new estimates for minor changes to the original and piling up hundreds of old worthless records. But that is not the issue anyway. The issue is that a record created in another table isn't seen via any available function through a direct relationship unless a pause is put into the script. Committing the records has no effect, nor does resetting the primary key. The pause HAS to be there for FM to see that the record is there through the relationship. I have never had this issue before in 15 years of Filemakering. And the question is whether I should add this pause as a safeguard to all of my scripts that assume FM can see a record through a relationship if it is there when it was created less than "x" seconds ago earlier in the same script.
  4. Hi guys, me again. I've solved this issue myself already but found it aggravating enough that I thought I would post it here and see if anyone else had any similar issues. I have a complicated script that builds an Estimate after the entry of some base information. It is quite fast for the work that it does and has been in use for a couple of years without any problems. The script builds a multi-tiered Estimate for printed materials based on discounting for different quantity levels. The user builds an Estimate from materials and work centers plus markup for the base Quantity then the script creates duplicate estimates for all of the higher quantities desired. Since the upgrade to FM13, the users have reported that just the very first material line that was present in the base estimate was missing on all of the higher quantity estimates that were constructed via a certain sequence and never edited. There are multiple triggers to update all of the estimates when the base estimate is changed, and if any of those triggers but a particular one is used, the missing first lines are generated properly if the estimate is edited after its original incarnation. If I run the offending script with debugger on and a stop right before the first line item is duplicated, it always works perfectly. We looked through the 12,000 or so Estimates generated by FM11 with the same script on the same server and there was never a missing first line item. I had to add a .01 second pause to the script in place of the debugger stop and now it works correctly every time(so far). The script checks for the existence of a related record through a relationship at that spot. It would not work using IsValid, Count, or an unstored FoundCount until the pause was added. Just curious if I need to be on the lookout for this anywhere where I use the existence of a related record created earlier in the script(which is in many of my scripts) because it could be wreaking havoc already and no one has noticed yet. Thanks, Dave
  5. Just as a follow up, the FM issues have solved themselves with no direct intervention on my part. I guess it simply needs a week or two to get comfortable? My console still won't allow me to add Scheduled Scripts, but that's a minor issue compared to what was happening before.
  6. Thanks for your advice Josh. I knew the layout changed as to how it was constructed, but I didn't think it would be quite so dramatically slow. I just visited Richard Carlton's site and didn't find a video on converting an 11 layout to a new theme. Do you know where I can find this? Youtube maybe?
  7. The server is a Cove XFM setup that uses a RAID array of Solid State Drives. Top of the line in every facet. It is the exact same machine we had FM11 server on reformatted and setup with FMS13. Windows Server 2008 R2. I don't think it's a server issue, because the server stats are fine all the time. We also bought a number of new client machines to meet the requirements. It's almost like the client can't redraw the screen at an acceptable rate or is hogging resources for something. It happens at different times to different clients on both Macs and PCs, but again far too often to ignore. Regardless of the new features and their neato abilities, you have to be able to use the database for the upgrade to be worth it. I'm hoping the theme change will be a simple fix that won't create a ton of work for us. It just doesn't make sense to me because everything is exactly the same as it was Friday when 11 was zooming along wonderfully. I have restarted the server after hours a couple of times as well but still the behavior persists.
  8. Thanks for the quick replies guys. We tested extensively using a similar(but not exact) setup on a sandbox network. Of course we couldn't hire a team of 150 testers from all nine of our locations to simulate a real load. We had 5 testers and even then, we are not performing work at the rates our expert users would. Scripts and finds are not the issue now. Typing in completely unformatted fields is. All files were checked for index problems and compacted before conversion. They were not slow in any fashion during testing, in fact everything seemed faster, but that might have been because we only had 5 users. Finds are only slow when users perform them on unindexed or related fields, we have been going through and closing all of those loopholes or creating new ways to get to that information. We've never had any issues on FM11 that caused literal work stoppage and errors like this as long as the server was up and functional. What effect will changing the theme have? I don't want changes to our layouts. There were a host of minor display issues that were easy to resolve and I expected that. I would be thrilled if our issues were limited to slow scripts and bad finds, but not being able to type data into a field is a whole new level of problem. It's almost like there's an intense flash movie running within the FM window during these times. No other applications seem to be affected at all. Thanks again for any advice you may have.
  9. Hi guys, We recently upgraded our servers and clients to Filemaker Server13/Pro 12/13 and FM is practically unusable at times(far too often) where simply typing a character in a field takes 10 seconds. It is literally unusable in this state, especially since our users are accustomed to 11 which had it's own issues with slow scripts and finds, but never anything like this that makes it impossible to even work and causes entry errors all over the place while FM catches up with simple data entry. This is a huge database solution used by 150 users in 9 locations and recreating it from scratch would literally take years with our current FM staff. There are some optimizations to be made and we are always looking to optimize everything, but this issue occurs when typing into a standard text field with no triggers, no special formatting, nothing to optimize! Our server console(not as nice as the old one by the way) shows nothing abnormal according to Filemaker and consultants we have had look at it. The server machine, disk subsystem and network are more than enough according to everyone we have spoken with. All of our current client machines easily meet the system requirements Does anyone have an idea of why this would be and what can be done short of a complete rewrite to alleviate this untenable situation? Neither FM nor our consultant had a solution short of starting over, and that's just not an option with the scope of this solution. . We have been using FM since version 6 and have never had anything like this so I'm not sure what to make of it. We tested in the only practical manner before the upgrade and didn't notice any of these issues. Of course we couldn't simulate 150 users in 9 locations. We may have to abandon FM for good if this can't be resolved and I really can't believe others have not had these kinds of issues so I'm hoping the forums can help more than FM with this. Worried we've made a huge mistake, Dave
  10. Hi, I'm trying to import records via ODBC from FM12 Server to FM11. I can successfully import using the query builder with a WHERE clause but this needs to be a repetitive automated process for a user. I would like to use the Calculated SQL text option and have no problem if I just use a SELECT statement with no WHERE clause to bring in records. As soon as I add the WHERE clause, FQL errors out. The text from the Query Builder is exactly identical to the text from the Calculated SQL text but the Query Builder works and the Calculated SQL Text does not. I have tried every trick I could find on this to no avail. Thanks for any help you can provide. I will post the exact Calculated SQL Text on Monday if needed. Thanks Dave I found the solution and I can't believe it hasn't been stressed in the ODBC documentation or in the forums. You have to make sure the quote marks that end up in the SQL text are "straight quotes" and not "curly" or "smart" quotes. Unchecking the box in File Options=>Text on the importing machine takes care of it. Thanks to anyone who may have looked into this. Dave
  11. I know, why would anyone be using FM 5.5! I have a client that uses FM Server 5.5 and FMP 5.5. They somehow have the access privileges configured to the layout and field level with no groups. This setup also has standard users (by their shared password) set to not be able to edit records in the Access Privileges Dialog, yet they can create new records and edit the new record. I had to add some new fields for them to use. The standard users cannot edit these new fields. They can edit the already existing fields. WTH? I need to have it so a standard user can only edit a new record that they just created but also be able to edit the new fields I just added to the database. They can edit the new fields if I put a checkmark in Edit Records in the Access Privileges Dialog, but then they can also edit records made in the past and the client does not want this but wants them to only be able to edit a new record they just created. This makes no sense to me. Can anyone help? Dave
  12. Hi, I would like to use this method for a client. Do you know of a way to get the XML text out of the Web Viewer and into an FM text field for parsing in FM 11 using a script? All I can get is the ridiculous mess of HTML using GetLayoutObjectAttribute. Thanks for the tip!
  13. Yes Steven, have been doing all of the updates for FM, Java(including the crappy one that broke the console) and MacOS in an effort to eliminate all the little glitchy things since we upgraded. Dave
  14. Hi, We are severely regretting the Filemaker Server 12 upgrade. It has been one issue after another since doing so. Most of the petty issues are worked out now except for one major recurring issue that we never, ever had a problem with in FMS10 or 11. We have a scheduled script that imports orders from 2 websites every 5 minutes throughout the day. This script and our server had run for 2 years with FMS 11 without stopping and without any issues of any kind. The machine was restarted on occasion for updates, but the FMServer never stopped running once on its own. About a week after upgrading, the script froze and somehow emptied Primary Key field in the entire Line Items table so we had all of the orders with no line items. We modified the script to not include any script steps referencing this field in the final Line Items table(set the field in a Temp table first then imported). Approximately 2 weeks later, the exact same thing happened again, all line item Primary Keys gone. It occurred on an approximately bi-weekly basis for 2 months so we shut the script off and now have been running it manually about every 10 minutes to 30 minutes with no issues for 6 weeks. We do not want to have to keep doing this manually. The script itself seems to work beautifully as long as 2 weeks have not elapsed on the server schedule or if it is run manually. Since the script is quite long and complicated, it is difficult to pinpoint what step(s) might be causing this. The server log just ends after the script starts and adds no more entries. If we restart FM Server it freezes again on the first run. If we restart the computer, it runs for 2 weeks again. There are no other scheduled scripts running when the freeze happens. We are now going to go through and painstakingly log the script steps to see if we can record when the stoppage is happening in the script. Although since it runs a few hundred times without error, I'm thinking this will not shed any light on the actual cause of the issue. Any other suggestions? Mac OS 10.7.5 2Ghz i7 8GB RAM Thanks in advance for any help, Dave
  15. Raybaudi, I have a script with 256 Replace lines in it for 256 fields. I was trying to not have to do all of the editing. I just changed the text field to number 256 times, slightly easier than changing all of the Replace lines. It defaulted to text field type because of the original import from a tab file. Thanks for the reply.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.