Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by T-Square

  1. Hello folks. Another hiatus from me, but I'm back with another one of my "Where did he come up with THAT one" Questions. I have a solution that I set up to use the Separation Model back a few years now, mostly to facilitate interface updates. That has generally worked out fine for my single user clients, but one of my clients has asked whether they can install their copy on a server and run concurrent sessions--and I frankly don't know. So, here I am with a few specific questions: 1) With a SM solution, does only the back end database go on the server? 2) If the front end is on each client, are there special steps to link the front to the back? 3) Of course, I assume that Server will handle record locking and data integrity issues with concurrent sessions logged in to the same database. Is that a fair assumption--or do I have to make any special alterations for a networked environment? I appreciate any guidance that folks can give me! David
  2. Personally, I have my Interface file locked down, and all users on this file are automatically logged in as "DBUser", which is en extremely limited account. I have the same privilege set in the data file, but there it has nearly full access, to give my clients full control over their own data. (Well, I limit access to a few administrative/configuration fields, scripting, and database design)... I'll note that my user base does not require individual privilege sets, and so I don't have to manage them much beyond "Yes" or "No." HTH, David
  3. Comment-- Thanks for the reply. I'm glad I'm not crazy that I can't find OnLayoutClose. Your explanation about the global fields makes sense (in an odd Filemaker kind of way...). Do you think I could use a regular record, and then use the OnRecordCommit trigger to clear out or even delete the record? I will try that out, although it seems weird to save a record, only to immediately erase it... David
  4. I've been a dormant FM developer, and am just having occasion to examine the Layout Script Triggers in FM10, and I am a little confused (this is a normal state for me). First off, I do not understand why there is a trigger for Layout Load, but not one for Layout Close? Next, I am not sure when the OnRecordCommit trigger actually runs. Here is the situation: a client wants to process credit card transactions, and a fellow developer has a technique that allows all sensitive information to be pushed up to the card processor (so my app doesn't have to have the security headache!). However, I will still need to offer a layout in which the user enters the card information to be sent up the river. I have created a layout that uses global fields to gather the input from the user, but I want to be sure that the information in the global fields is cleared out ***no matter what*** when the client leaves the layout or completes the procedure. If the user clicks my "Register" or "Cancel" buttons, I see no problem--I just script the clearing. But what if they don't? My first thought was, well, run a script to reinitialize the globals when the layout is closed, but... there isn't an OnLayoutClose trigger. Next I thought, well, what about using the OnRecordCommit trigger, and I began to experiment with a simple "Hello, world" kind of script attached to this event. My understanding of Filemakerdom is that a record gets committed when the user attempts to move to the next record, or clicks outside the entry fields on the layout, but when I try this with my test script, nothing happens. So, I throw myself on the mercy of the FMForums court of opinion: how might I proceed with this sensitive and critical process? TIA, David
  5. Barbara-- I think Colin is trying to set up an auto-mail routine based on field validation. Colin-- if you were using FMP10, you would be able to use a script trigger (http://www.filemaker.com/products/fmp/script_triggers.html) to send your email, and additionally in FMP10, you can use the SMTP Send Mail options the other posters have suggested. HTH, David
  6. Amy-- You're missing a basic tenet: Establishing relationships between tables in separate files doesn't import the table--it simply creates a pointer to the remote table. The data remains in the other file and is edited/added to that remote table. HTH, David
  7. Just a programming point: it is more common to use 0 for No or False, rather than 2. With No set to zero, a simple assertion of the field is its own test. This is simplified as: If(Answer; "Yes"; "No"). This assumes that Answer has only two values 0 & 1. Your calculation suggests that there is more going on here, though, since you have separate tests of Answer for two different values. David
  8. Not knowing really what you're trying to do, you *could* set your script up so that it gets the source fields passed as a script parameter. You would then break the parameter up into the fields and paste the values in using set field script steps, one per field. Another way would be to use lookups in the new table, based on relationships back to the original tables using the calling record's ID. David
  9. More specifically, store the inventory information in *one* table, and have all the other layouts display the data that is stored in the first table. You enable the display of this data through the relationships that bcooney mentioned. David
  10. I don't see why you would want to calculate 2007 taxes in 2009. From a business perspective, you will run afoul of recordkeeping requirements if you don't actually store the amount you billed someone back in 2007. Your accountant (and the IRS, if you're in the U.S.) will bark. Far better just to put in the amount. It can be supplied by a simple calculation. If you need to track multiple tax rates or multiple time frames, I think Michael's suggestion of a lookup is best. David P.S. -- Welcome to the Forums.
  11. John-- From your brief description, I'd say you should look at Privilege Sets. Assuming that all 3 users would have the same privileges, I would set up one privilege set for all of them. The admin would use [Full Access]. David
  12. Tom-- This certainly is a different problem. I imagine that from a technical perspective, your approach would work probably fine. I wouldn't do it, though, because it will complicate your solution and make it harder to manage on an ongoing basis. Using standard join tables follows traditional database design practices, and makes it easier for others (and you, later on) to understand what you're doing. Your solution also doesn't really gain you anything with regard to data storage, since you always will have two key fields per join record. Ultimately, I think the real question is: How many of these arbitrary joins are you likely to use, really? In my own projects, I have found that there is a phase where I am in Global Solutions Mode, and I work out a Grand Unifying Solution to Every Conceivable Oddity. Unfortunately, the GUSECO ends up being obtuse, and accounts for problems I don't really have. And in that complexity, I have years of nightmares trying to remember what I was doing and why. In your case, I wonder how many of the arbitrary joins you mention will actually come up, and if you couldn't just use standard join tables for those. This is related to my second question... How do you propose to make use of every one of these arbitrary joins? On the one hand, you could use your Grand Junction Table in scripts to locate particular sets of data on the far side of GJT. I envision some messy scripts, though. On the other hand, you could leverage the data in the Relationship Graph. But if you do that, you don't really gain anything over separate join tables. This is just my own initial opinion on this. Cheers, David
  13. John-- Thanks for the tips. I may try out BaseElements, although I am not sure I can go for the purchase price right now. Cheers, David
  14. I have a solution that has come along from FM4 through FM6, FM7, and I am looking at moving it to FM10. When I converted to 7, I rebuilt the structure to use the separation model, which was a major undertaking on its own. Consequently, I wasn't ready to try eliminating the many global fields I had. What I did was to move all the global fields into a Globals table in the UI file. Since I've never been a fan of global variables, I am now looking at eliminating as many of the 115 global fields as I can and replacing them with script variables (or other tricks). My question is: does anyone have a principled method of converting them over? I am concerned that I will miss a reference to one of the globals and send out a package that only breaks when the user tries to do something obscure (that I had forgotten about). I thought about just deleting the variables and then looking for all the entries in a DDR. But that seems a little chancy (which global got used where?)... I thought about iterating through a cycle where I create a DDR, change all the references I can find for one variable, re-running the DDR and checking again. But this really seems like a long and arduous process. I am having a tough time with this also because (in my infinite wisdom, ha ha) I used lots of short scripts that focused on simpler tasks, and then stored the results of each little script in a Global, which the next little script would use. So, keeping track of where all the variables gets used is confusing to me on the best days... If anyone has advice, suggestions, or encouragement to offer me, I would relly appreciate it. As it stands, I keep putting this off for other things (like repainting the house). Thanks, David
  15. In your script, first go to the layout that will be your destination. Then enter Find Mode. Next, Set the search fields with the parameters you have passed. Finally, Perform the find. Or am I missing something? David
  16. Comment-- I apparently got it in my head somewhere that using a calculated field in a relationship would result in poor performance. That's probably because at some point in the past, I had a much gnarlier data structure... I see that this approach will work for my needs. Thanks for opening my eyes. David
  17. LaRetta-- Please accept my apology. I was not trying to test your psychic abilities. I had wrestled with the problem for quite a while before I posted, and I wrestled with your example for another long while. When I said I was going to keep digging, what I should have said was that I suspect I am trying to find a solution using the wrong method, and under the circumstances, I will dig for a better one. It truly was not an attempt to get others sucked in to this. For what it's worth, I am going to probably go with a scripted solution, as indicated in my modified version of your example file, attached. The modified structure might also give you an idea of the conundrum (but I'm not asking you to put any more time into this, really!). Sorry for the trouble. David GrandparentalMod.fp7.zip
  18. LaRetta, Soren-- Sorry I wasn't fully clear. A subscription can be made up of different services. So, in my example, Subscription 5 is made up of services p AND s. I only want to see the p services listed. To put in real terms, a Home delivery subscription includes a (primary) veggie box service ($17) and a home delivery service ($5). I am looking for a list of the veggie box services only. LaRetta, I looked at your structure, and was intrigued by the idea of adding the Customer table at the other end of the chain. I tried it, but unfortunately, this second TO doesn't have the same CustomerID active, and thus doesn't filter the record set. As for your final suggestion, LaRetta, of using a calculation, that is essentially what I have already. I was trying to see whether there was a way to do this without a calculated field in part because ever since I went with the separation model, I have had an aversion to creating calculation fields in the back end of a distributed database. Thanks for the suggestions; I'm going to keep digging. David
  19. Sorry for the subject; I couldn't imagine a clear subject that wasn't as long as the problem. Short of a calculated field, is there a way to use an attribute of a grandparent record as a relationship component between the parent and child? In my situation, my parent record is a Customer record, the children records are Deliveries, and the grandparent is the Subscriptions record, which has a primary service field. Each delivery record identifies the service it represents. I am trying to get all the Delivery records for one customer that are the primary service for that customer. For example: Customer C uses Subscription 5. Subscription 5 has Primary Service p. I want Deliveries with Customer C, Service p. Previously, I have done this by creating calculated fields and scripted finds to identify the primary service, but this is computationally slow. I have tried putting the Subscription table in between the Customer and Delivery tables, but when I tried navigating from the customer to the delivery layouts, I got every delivery the specified type (regardless of the customer). I am hoping someone has a suggestion. TIA, David
  20. I figure I should close this out. Comment, you were right to question the GTRR step; it turns out that I was getting an error 414 (Layout can't display result). Combine that situation with a (seemingly minor : ) change in the error test from "If[Get(LastError) = 101 ..." to "If Get(LastError) ...", and you get a nifty endless loop. Now, (he says, wiping some egg from his face) Comment, you questioned this step, and I'd love to know how to do this differently. Basically, I was using the GTRR to test for a record that matched the date in the remote file. If there IS a record there, then keep going along, otherwise, you can use this date. Would it work to have: If[RemoteTable::DateField ... and would that work better overall? Thanks, David
  21. I am sure that this has been covered before, and I am sure it's a simple calculation, but I can't figure out how to find it or figure it. I want to calculate the date of "Next Tuesday" (or Wednesday, etc.), regardless of what today is. So if today were 04/20/2009 (Monday), the date would be 04/21/2009 (Tuesday), but if today were 04/22/2009 (Wednesday), the date would be 04/28/2009. TIA! David
  22. Vaughan, Comment-- Thank you for your replies. I will examine the situation with these data points in mind. Vaughan, I don't think there are any empty keys in the data, so I don't believe that is the source of my problem. Comment, I recognize that my original post was dense; I did try to provide context, but clearly I didn't succeed very well. As further information, the application is a delivery tracking system for farms. The farmers deliver to a set of sites on a given day of the week, which is defined in the site record as a simple text field filled in from a fixed value list of the days of week (that's the GlobalsDelivsSiteID::DelDay variable). Customers select a site for pickup and their choice of site determines the delivery day. Clients can also choose to have deliveries made every n weeks, which is set in the client record (that's the _g_PeopleSched variable, which is a number field). Finally, the farm can designate any date as a SkipDate, which is a day on which no deliveries will be made. SkipDates is a table with only one date field SkipDate defined. There is a relationship: Globals:_g_DelivsDelivDate<=>SkipDates::SkipDate to handle the GTRR. The script included is supposed to locate the next date whose: 1) day matches the site delivery day 2) week matches the customer's schedule, and 3) date is NOT in the SkipDates table "Next date" is additionally defined to be: 1) In the future 2) More than p days from today, where 'p' is a user setting (to allow for a delay in adding deliveries), and 3) After the customer's last delivery There's more, but I think I'll just try to rewrite the script in a more sane way. David
  23. Well, I see that there have been a hundred lookers and not one taker. Oh well. I will sit down at the client's machine in the near future and try to figure out a workaround. Most likely what I will do is use a value list to establish a dayname/daynum tree, and check for the next available date that uses that daynum. I am certain that there is no doubt a slick Comment-ish single calculation that will yield the next date to use without all this gnarly looping and comparing. David
  24. My clients are having trouble with a script that I wrote under FM7 that they are trying to run in FM10, and I am completely stumped. The script runs fine on my machine under 7, and it even works for me on FM10 trial version. For my clients, though, the script locks up in an endless loop (but only under 10). The script (listed below) is supposed to locate the next date whose day name matches the customer's delivery day (which is determined by which site the client gets their deliveries at). Once the system has found that the days match, it checks to see whether the date is found in a table that lists dates that my client is NOT working (holidays, etc.), and if the date is found there, the script keeps going until the next matching date, at which point it stops, and the date value is set. The various global fields are set in the calling scripts, and there are records in the SkipDates table (which means that there won't be an error 101 when trying to GTRR). The Delivs - System View is a layout that includes all defined fields for the table. Unfortunately for my client, this script never stops when they run it under FM10, and it keeps twirling twirling into the future, never stopping for any days. Time keeps on slipping slipping slipping, into the future... I have verified that the data set being used is valid--and in fact, the same script works fine on the same data under version 7. Can anyone with more experience with FM10 see why this script would work on one machine, but not another? (BTW, I know this script is brutish, but hey, it works--or did until this) TIA, David ------------------------------------ #This macro cycles through to the next delivery date and sets NextDelivery accordingly. #It uses the delivery day specified for the client's site and delivery schedule. #Called by: Delivs - FindNextDelivDate Delivs - Change DelivToDonee Set Error Capture [ On ] #Initialize global counter _g_DelivsWeekCnt Set Field [ Globals:_g_DelivsWeekCnt; 1 ] Commit Records/Requests [ No dialog ] Go to Layout [ “Delivs - System View” (Delivs) ] Loop If [ DayName(Globals::_g_DelivsDelivDate) = GlobalsDelivsSiteID::DelDay /* Days match */ ] #Now check against skip days Go to Related Record [ From table: “GlobalsDeliv to Skipdates”; Using layout: ] [ Show only related records ] If [ Get(LastError) /* No skip date related to the date found */ ] Set Field [ Globals::_g_DelivsSkipFound; 0 ] Else Set Field [ Globals::_g_DelivsSkipFound; 1 ] End If Commit Records/Requests [ No dialog ] If [ Globals::_g_DelivsSkipFound = 0 /* The selected date is NOT in Skipdates */ ] Exit Loop If [ GetAsNumber(Globals::_g_DelivsWeekCnt) >= Globals::_g_PeopleSched ] Set Field [ Globals::_g_DelivsWeekCnt; Globals::_g_DelivsWeekCnt + 1 ] End If End If Set Field [ Globals::_g_DelivsDelivDate; Globals::_g_DelivsDelivDate + 1 ] Commit Records/Requests [ No dialog ] End Loop Go to Layout [ original layout ]
  25. Welcome aboard. Your post is a little confusing: are you going to continue to use Excel? If so, it sounds like you are wondering about how to import the data consistently, on a regular basis, which is a problem I'm not going to answer (mainly because I'm no expert on the ins and outs of FM importing). If your plan is to use Filemaker to capture and store your data, then that's different. In that case, I'd create a single unified table for products that contained ALL the product attributes needed for the different reports. Then I'd build the reports as separate layouts, each with the view I need in that report. David
  • Create New...

Important Information

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