Jump to content

T-Square

Members
  • Content Count

    792
  • Joined

  • Last visited

  • Days Won

    1

T-Square last won the day on October 16 2019

T-Square had the most liked content!

Community Reputation

1 Neutral

About T-Square

  • Rank
    Datatrooper
  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
×
×
  • Create New...

Important Information

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