Jump to content

KirkR

Members
  • Posts

    68
  • Joined

  • Last visited

Profile Information

  • Industry
    Software Development
  • Gender
    Male
  • Location
    Arizona

Contact Methods

  • Website URL
    http://www.performancebts.com

FileMaker Experience

  • Skill Level
    Expert
  • FM Application
    19

Platform Environment

  • OS Platform
    X-Platform
  • OS Version
    Mojave

FileMaker Partner

  • Certification
    Not Certified
  • Membership
    FileMaker Business Alliance

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

KirkR's Achievements

Enthusiast

Enthusiast (6/14)

  • First Post
  • Collaborator
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

0

Reputation

  1. Tom - using your "Modern commitment" approach, and having problems with one field presentation type; a drop down calendar. I cannot get the drop down calendar to be a picker - it opens, but content is not selectable. The field can be entered manually, but the picker is not. It is almost like the calendar icon attached to a date field, is effectively attempting a commit??? Added the date field to your example, to confirm that the behavior was not specific to something in my implementation. 

    For now, I replaced the field with a button bar segment, with the date field as the label, and a popover using a calendar picker (of my own design), to populate (or clear) the date field. But I'd like to figure out why the drop down - just on the field type calendar/date is not functional. 

    Can you confirm this is not something stupid (a common malady) mistake that I am making?

  2. Can Supercontainer work with FMGo 12, without server connectivity (like for the iPad/iPhone user at a remote construction site without cellular connectivity - as in 90% of the world)? I can't seem to decipher the deployment options @ 360Works relative to an IOS deployment.
  3. FM9 Server Adv - IWP deployment. OS X 10.5.6 Multiple databases - each client has their own set of applications. Multiple customer branded web pages. Apache configured for VirtualHosts, one IP, branded web pages in separate directories, sub-domain access set up in hosts file. Web page contains link to each clients set of databases. This works perfectly. Problem comes when .... 1) cancel at login in iwp_auth.html 2) Scripted exit database Both return to iwp_home.html - and not one that is unique to the customer, so they can never get back to their own set of databases without re-entering the subdomain URL Replacing the Javascript in the header for top.location ? How would this deal with multiple customer companies?? Any solutions??
  4. 1st Field) get(recordnumber) to populate a calculated field (stable) 2nd Field) a global field with auto-enter Get (RecordID) and "do not replace the value in the field (if any)" unchecked, so that it will dynamically change on selection. When you select a record, the global field will match the calculated field and then you can do something with the result - set text or background color, set a radio button on the row to TRUE to indicate selection, use it in conditional formatting, whatever. Conditional formatting is not IWP compatible, nor are transparent buttons (see next paragraph), so a SELECT button on a layout row is my preferred method. However, I am unsure that scrolling to a record itself is sufficient to trigger the change. I have always placed a transparent button on the layout row, so that when a user clicks on it, the change occurs.
  5. Another approach might be to create a second field for edition, and a 3rd field, which is job# concatenated with Edition. In fact, I might consider another concatenation for your job number. The auto-enter number includes year; what happens next Jan 1? Create a YEAR field, and concatenate this with the serial ID for display purposes. SO, the concatenated field might be - YEAR & "/" & pk_jobID & editionfield This also affords some great flexibility in identifying how many jobs get exceptions (editions) by counting the editions field, and finds based on year. Further refined ..................... The auto-enter serial number is going to update every time you create a new record - no easy way around that and keep referential integrity intact, nor do you really want to. You will need to add another field, with the job record ID in it, but NOT an auto-serial number field. It will be an auto-entry field, with the calculation set for entering the content of the auto-serial number field. Check the box on auto-entry to "do NOT replace existing value of field (if any)". When you create an EDITION, don't create new, but duplicate the existing record (there is a script command for that). The Serial ID will change, but all the other content will remain the same, INCLUDING the newly created JOB ID field. You can then edit whatever content you expose to the user, and your original job record remains intact - nice for comparing EDITION deltas. The concatenated field that takes YEAR, JOBID and EDITION, should use the auto-enter calc field for JOBID, and NOT the auto-serial number field. That way, the JOBID number will remain the same for duplicated records, just the EDITION character will change. You'll end up with records for JOBS and additional records for EDITIONS, each with their own data, editions being a change or superset of JOBS. If there are 4 editions to a job, the auto enter serial number field will have 4 IDs (Not to be seen by users), but the JOBID will be the same (result of duplication and not change checked in field auto-enter), and the concatenated field will have the YEAR prepended, and the EDITION post-pended to the JOBID. That should get you there. Summary: pk_JOBID - autoenter serial number Date field - auto-enter creation date JOBID field - auto-enter calc from pk_JOBID EDITION field - maybe a custom value list of A-Z? for ease of entry. WholeJOBID - the year from date field & JOBID & Edition According to the stored format for DATE, the LEFT, MIDDLE or other parsing command to get just the YEAR from the date field will have to be determined. Listings sorted by pk_JOBID (not that a user would ever see this field), would show record creation order A match field or find command for a JOBID would get you all editions, as the EDITION field is separate. Use the WholeJOBID to display a FIND of JOBID (again, JOBID would be another field that the user would never have to see, at least in reports).
  6. Mark, Kirk here again - what is this script that takes 3-4 hours to run? Don't necessarily need to see code, but what is the function performed. Again, I think there are simple design changes that might make massive performance improvements.
  7. I believe that if you shift to a couple of self-joins, particularly for those things that are taking long times, you should see radical speed improvements. I posted a global field URL_match approach to one of your comments. It is really quick to implement. If you are stuck, comment back, and I'll walk you through it. If you have something else that is more time intensive, describe it, and we'll see about walking through a quick and dirty test, so you can compare the speed. I think you'll be amazed.
  8. Mark, Filemaker's Table Occurrences (T.O.) is a powerful construct. Let me see if I can provide a simple example. TO1 Create a global field in that table. This is going to be used as a match field to another T.O. For the sake of this simple example, let's say you have a field named URL. Create a second field, as a global variable, and name it URL_match. Duplicate the TO1 parent table - you now have a second instance of the same table - a child table. Set a relationship between the URL_Match global field in TO1 to the URL field in the child T.O. Use SET FIELD to set the global URL_Match field to a URL that you know is in the URL field. Now the child T.O. will contain (virtually) only those records that match the global URL_Match field condition. You can create layouts with these fields from the child table, knowing that they will only contain the fields that match the global URL_Match. In the parent T.O. (it will also appear in the child T.O), create a field that does a COUNT (pk from child T.O.). This field IN THE PARENT T.O. will contain a valid count of the # of records in the child T.O. NOTE: The same field in the child T.O will NOT contain valid info - counts in a record do not work to count the records in the same table, but do work to count those in a related table. This technique can be used with globals that are changeable (as in the example defined), or global constants, or multi-relationship conditions. I have a person list, where I want to edit just one person. Rather than doing a find (time consuming) I set the global variable on the parent side of the relationship, and the child T.O. has THAT person's data ONLY - instantaneous in my DBs and probably nearly so in your massive example. The power of T.O.s - took me forever to get the concepts. Now I use Anchor-Buoy modeling (a.k.a. squids) for everything. Individual table occurrence groups (TOG) instances for almost every layout - and very little code anymore. My core data model is the primary T.O. and their primary relationships. For each layout, I have a new T.O. model, using just the T.O.s that are relevant to what I want to display, and relationships that are specific to what I need to display. Few if any FINDs or other time consuming script executions ever need to be run. There are some excellent white papers out there on TOG, self-joins and anchor-buoy modeling. I think you will find this approach vastly simplifies
  9. Creation of records only occur when you issue a NEW RECORD command, or add a record in a portal when the relationship defines "create records through the relationship". What are you doing that is creating the new record??
  10. Each layout has a context; a table occurrence (T.O.) that provides the data fields associated with that layout / screen display. Creating a new record, creates a new record, no matter what layout you display the fields on. Layouts provide the vehicle to view different (or common) fields from a T.O. If you create a new record, then switch to another layout that has the same fields from the same record, the same data is displayed. "GoTo Layout" will move to another layout of the same record in the database, and you can have the same, or other fields from that record on that second layout, extending the number of data entry fields, if required. Normally, there would be data entry layouts, and data display layouts (reports). Your explanations do not describe what you are trying to accomplish, so we are having difficulty assisting you. I have no concept what "one is web and one is something else".
  11. One of the prime reasons for performance issues in FM is the generation of indices. More often than not, many more fields are indexed that are necessary for the application. Although indices make for faster searches, constantly regenerating these indices eat processor and memory (emphasis on the latter). Relational design has lots of pitfalls in performance issues. Took a VSAM flat file DB on a mainframe to a Oracle relational model (375 terabyte DB of 3 months window of data, changing constantly) on a 256 way Sun E10000. The processing time went from under an hour to over 27 hours to produce the reports - the migration project got canned. Filemaker has a unique and powerful construct that affords significant performance improvements. Using global match fields and self-join table occurrences, you can have many of the select capabilities performed with near zero performance impacts. The lesson that I guess I am attempting to communicate is that there are ways to get or restrict performance, mostly in design. Many factors impact performance, and FMs table occurrence model affords significant performance benefits, but requires some good - and possible unique - design approaches.
  12. Filemaker 9 Advanced running on OS X. Filemaker (same license #) running on Windows. (nice part about FM license - dual platform, single license legal) Database opened on OS X. From Windows - Open Remote. The OS X side shows up on Windows in the HOST side of the dialog, but the FILES side is empty. Hard typing a IP/Filename enabled the OK, but times out. The network file path is correct (it works from an external PC). IF the Windows box is stand alone, this exact setup works from OS X. It is the virtual machine setup that does not seem to work. There is a shared drive on the Parallels VM side, that is the OS X home directory. Any suggestions? Painfully workable: I would prefer to not deactivate the FM code on the Windows side of my OS X box, to activate it on the external Compaq desktop, as I troubleshoot code using my Macbook Pro, although I know this works. If Windows had a decent screen rendering model, none of this would be necessary, but as Windows is incapable of producing accurate screen representations, it always seems necessary to test on both platforms.
  13. There are 2 IP addresses in play here; the external IP that whatsmyip (ipchicken.com is quicker and more fun to remember :-) shows, but that needs to be mapped to an internal address (the IWP published address) in order for it to be seen through the NAT (Network Address Translation) firewall. On the external IP, Port 591 is a Filemaker registered port, so you should not have any conflicts on the web. Internally, it does not matter what non-conflicting port you use, as long as your router knows the mapping between the external and internal IP and port.
  14. Apparently this is a "broken as designed" - LIST views that work fine in FMPro, work like this in IWP -( . Specifically, in the browser, clicking on a client, hides all client records above that record in the list, and only allows editing of that record selected. Clicking on another record does nothing after that point. There are a couple POTENTIAL (read:speculated but untested) work arounds, each of which change the behavior of the client screen. 1) Create a SUBMIT button on the right of the records in the LIST VIEW, that when clicked, would restore the entire list. Easy to implement, however, it has the visual discontinuity of A) removing the display of all records in the list above the click point until after SUBMIT, : leaving the display of records after the record selected, displayed, but not active. Records (at least the one clicked) remains editable until the SUBMIT (or DONE, or OK, or GEORGE - any text label that works) button is pressed. (easy, but not pretty or recommended) 2) A little more work (not much) would be to lock the field entry in the list, and create an edit window and button. Clicking EDIT would open a window with just that client's records displayed. That would also more room for other client information, like the program name, or any other details. 3) Create the list in a portal - a scrollable and editable view into the table. The portal does not exhibit the same characteristics as the list view. If it works, it would retain the "edit in list" capability. In application, (combining 2 and 3) It would probably be best if the list were just a "select record" function for the parent fields, assuming that the PORTAL is created as a result of cartesian relationship.
  15. Conditional Formatting does not work under IWP - Instant Web Publishing. However, using the same techniques described above, you can set a radio button field, say with the text label SELECTED. This works great in both local and IWP setups. Just set the field state, and skip conditional formatting.
×
×
  • Create New...

Important Information

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