Riley Waugh

I have a databese hosted on the internet. It has several tables. Each table has an AUDITLOG field to track certain activity. When working in the database via FM remote everything works as designed (or perhaps I should say as "intended" ) When entering data via browser to IWP, the AUDITLOG field from table 2 is populated with data from Table 1. The AUGITLOG field for Table 1 looks like: Evaluate ( Quote ( Table1_pk_Field & " | " & Get ( AccountName ) & " | " & Get ( CurrentTimeStamp ) & " | " & Get ( ActiveFieldName ) & " | " & Get ( ActiveFieldContents ) & "¶" & _AuditLog ); [Table1_pk_Field; Table1_field2; Table1_field3 ]) The AUDITLOG Field for Table 2 is the same (but with table 2 fields of course). How can changes made in table 1 fields appear in table 2's Audit logs? This does not happen when modifying the records via FM Remote, only when using IWP in a browser. Any ideas as to why or how to trap the problem to analyze it? If data can cross tables, how can I trust ANY data?

Thank you Vaughn and LaRetta. The lack of a stored result in the NoteCode was a problem for me until I saw the double self join in Notes table. Thank you all for your help.

I agree with your comment about serial numbers if used as primary or secondary keys or a unique identifiers. I am not using it in that way. Each record in every table has a unique identifier. All case notes must be entered and kept in unchangable chronological order. They may be entered on a date after they occured, and there may be multiple entries on a date, so using a date is not productive in this case. Also, there may be no gaps inthe serials numbers... that could indicate that a case note had been deleted which is a major no-no. They must be tied to the client (in this example client ABC-123) with out using any other idnetifier like a name as they must remain confidential to outside reviewers. Each case note must be identifiable so that a supervising case manager can talk about a particular note in case rewiews. Hense, it should be: 123 (as a tie to client ABC-123) and a running serial number such as 001 so the individual note can be taked about. therefore I would like 123-001, 123-002, etc. I have done this sort of thing many times inthe past. Should be easy with variables. I just have lost my mind an can't figure out the formula for the field.

Could it be Alzheimer's? I want to do the following, and it should be easy but I'm lost. I have a relational database. Parent record is a client with a unique Client_ID of, say, "ABC-123". Case managers make case notes about the client. Case notes need to have serial numbers based upon the related parent file Client_ID. For example, the case notes for client ABC-123 should be numbered 123-001, 123-002, 123-003, etc. This should be like a FileMaker 101 kind of problem, so send me back to kindergarten. Help.

Thanks a lot for the quick and helpful replies.

I want to create a Runtime database that will be put on unknown desktop. Have a script to create a copy of the database on closing. I cannot seem to get the file path correct. I have: SetVariable [$Path;Value:"Filewin:" & Get ( FileMakerPath )& "Backup/" & $BackupName] Save a Copy as [$Path; compacted] where the folder "Backup" resides in the runtime folder. $BackupName is set in a previous step and works fin ewhre I set the path 'manually'. I cannot figure out making the Get (FilemakerPath) part to work. Where am I going wrong? Also, is there a rather simple way within Filemaker to script the creation of the folder "Backup"?

HI all, I have been away for a few years. Now am back to useing Filemaker and jumping to FM10. I feel like I am starting all over again. Nice to see so many familiar names in the posts! So, here is my issue: I have "Clients" table. I have a "Siblings" table. Clients have siblings and SOME of these may be clients (by virtue of being minors with a parent in prison). I use a portal viewed in the "Clients" table layout to enter siblings (and create records of siblings in the "siblings" table). Based on operator/enterer decision (i.e. a minor and with the same incarcerated parent), a field, we'll call "SibClient", in the portal is checked which indicates the sibling will also be a client. I have the field set to run a script on field modification... the script creates a new "Client" record for the sibling and sets various fields to minimize data entry. So far, so good (though perhaps not the easiest or best method). but, here's the rub: I want client A's record to show all siblings (cients or not) in the portal wherein the records are created. I also want Client A's sibling's record, we'll call client B, to show all Client B's siblings (including client A and other siblings who may or may not be clients). I don't know if this makes sense. I don't know if I should: 1. make ALL siblings create records in the "Client" table and code them as clients or not. 2. Use a Join table of some sort. 3. Buy a few books on Filemaker 10 and catch up. I will do #3, but I want to finish this little file to show to a colleague to convince her to get away from Excel as an answer to all data storage issues. AnY help is appreciated.

The script in the MAIN db shoould only call the script in the CONTACTS db. All condional sctipting should be done all in the CONTACTS db. Allow User Abort [Off] Set Error Capture [On] If ["Status(CurrentRecordCount)=0"] New Record/Request Exit Script Else If ["Status(CurrentRecordCount)=1"] Go to layout [where ever] Exit Script Else If ["Status(CurrentRecordCount)>1"] Go to layout [where ever] Exit Script End If End If End If

Report Mode (I assume you mean 'Preview Mode') displays the way the report will print. In browse mode Summary parts will not show as they do when printed. A method Filemaker uses to show you report without printing it... FM does not have a "report" mode like some other dtabses and this is how they get around this.

Obviously the user must do something to exit the script, why not the cancle button. Depending ont he situation you could pause the script for a set period of time the exit automatically. Knowing what your script is intended to do, what are the users options, and why the user woud want to cancel, would help to better answer your question.

Bob, We're about to get into the "repeating fields vs. related files" thing. If you have a separate file for user names and passwords related back to the main file by a unique field such as the id you give to each new user, (or whatever will allow you to relate the main file to the user name and password file such as a calculation field which is a concatenation of first and last names)then you can show the information you are looking for either to just the logged inuser by relating name to name, or show all the usernames and passwords in a portal. Showing all would be done by relating the files by a constant (a field in the main file which always has a constant vlaue like "1" related to a field in the password file with the same constant value). MainFile Fields: FirstName, LastName, record ID, title, Constant, WholeName=LastName, &', " FirstName PasswordFile Fields: WholeName, Constant, UserName, Password Relating constant to constant will show all records in a portal. Relating WholeName to WholeName will show only the related record in the portal. I believe this approach allows you control over the creation and change of passwords, and a much better control over showing them to users.

Oh, I meant to add... I agree with LaRetta... labels are cheaper than printer repair.

I have never thought much about this until the other day when soeone asked the same question on another forum, and I offered this: If your labels had, say, 30 labels per sheet, the you could do the following... Create a field called "BlankRecord" Create a field called "CountPrinted" Create a global Field called "SetLabelStart" Create a global Field called "Remainder" Create a field called "BlankMarker" Create 29 blank records. (if your sheet holds 30 labels). In the blank records set the field "BlankRecord" to a value of "1" just as a wau to find the blanks later. Set field "SetLabelStart" to "0". Script 1 = "Find the number of records to be printed #however you determine how many labels to be printed Perform Find [Restore] Set Field ["CountPrinted", "Status(CurrentFoundCount)"] Set Field ["Remainder", "CountPrinted - (30 * Int(CountPrinted / 30))"] Scrip 2 = set the correct number of blanks to print and reset SetLabelStart #need to do nothing except add the remainder of starting label is the first label... meaning there are no found blanks. If["SetLabelStart = 0"] ["SetLabelStart", "SetLabelStart + Remainder"] Exit Script Else #you must find only your blank records ... by finding for the "1" in field BlankRecord PerforPerform Find [Restore] Go to Record/Request/Page [First] Loop Set Field ["BlankMarker", ""1""] Exit Loop If ["Status(CurrentRecordNumber)= SetLabelStart"] Go to Record/Request/Page [Next] End Loop Set Field ["SetLabelStart", "SetLabelStart + Remainder"] End IF Script 3 = Find and Sort and Print #you must now find the blank records you have marked to print with the "1" in the BlankMarker field AND your records you really want to print Perform Find [Restore] #now you sort by BlankMarker in DECENDING order to put the blank records first (and then you can sort by however you want your real records sorted) Sort [Restore, No Dialog] Print Now you need to clear the "BlankMarker" fields Script 4 = Clear BlankMarker #Find all the records where BlankMarker = "1" Perform Find [Restore] Go to Record/Request/Page [First] Loop Set Field ["BlankMarker", "" ""] Go to Record/Request/Page [Next, exit after last] End Loop -------------------------------------------------------------------------------- That should do it. (You could incorporate the loop in script 4 as the first part of script 2... I put it here last because it is logical to think of clearing the fields last) You only have to make blank records once.... you just keep using them and it is all done behind the scenes. Now, be advised that I have never really done this, but I think it should work. -------------------- Riley Waugh WRW Solutions St. Croix, Virgin Islands

Ugo.... when Ray sees this post he will do it in one line.... ten words or less.

same thing... different look That's what makes this so interesting

And the take the next word, etc.

Ugo... So then I would begin with something like Abs(TexttoNum(LeftWords(DiscountTest,1)-100))*.01 or 100 - TexttoNum(LeftWords(DiscountTest,1)) * .01

Ugo... Check me if I'm wrong, but on $100 50+10+10 is 100 * .50 = 50 * .90 = 45 * .90 = 40.5 But 55+5 on the same $100 is 100 * .45 = 45 *.95 = 42.75 I need to know if this is right before we begin on any calculation.

Lee, I think we should all chip in and get you a simple WinXP system for Christmas.

Or, your line wieght is set to none.

Diana, while it is rather counterintuitive, use a script step, "Send Message"

It may be that the most appropriate thing here is a related file. In many solutions I make, it is important to deal with the notes, chronologically, by creator, by creation date, etc. and sometimes to allow only the user to see his own notes, etc. If you make a related file that contains the note entry, along with a few fields for date and time of creation and creator, then you can use a variety of relationships to deal with the note. My primary field is police work. Notes are tied to case numbers. The relationship is made in the crime report file and related by Crime Report number (CRN) to CRN. I allow creations of related records. In the report file a portal is placed containing the note fields. When a user clicks in the portal to make a note, a new record is created and the CRN in the note field is automagically completed with the current CRN from the report file. So, you could do the same with user name, job number, whatever. A sort in the portal will sort which ever way regarding creation order. then you script to the last record. In short, with related file you have a lot of control.

Since Word is your normal output format, and since Word is probably familiar to all users, I would start there. With word (Office XP anyway)if you open a document on your LAN and others try to access it they will get a message that it is in use and would they like to work on a copy for later synchronization. Sure, why not. I make a few changes and close my copy. One person in charge of the project can control the master file and is presented with graphically identified changes to accept or reject. A history of changes and users can automatically be maintained. The most important issue with either method is reviewing and accepting changes... who decides and how? If all users have equal weight, each person can throw out any other's modifications and now we don't know what good ideas were lost and we are, practical purposes, left with the last user (change) having all the control. The control ove the project is more important than the method... but I would stick to Word.

John, A looping script starts in a record (usually record one)... then comes the script step LOOP... then an action... now go to next record [exit after last].... then END LOOP. Go To Record/Request/Page [First] Loop set field {whatever, whatever] Go To Record/Request/Page [Exit after Last, Next] End Loop However, if you want a report to count categories, then you probably want the following.... Make a summary field, we'll call it Cat_Count, and make it a COUNT of field "Catagory". Make a new layout. In the BODY put the field Category. Make a SUB-SUMMARY Part. Set when sorted by "Category". In the sub-summary part put you new summary field Cat_Count. Enter browse mode. View as a list. Sort by "Category". Enter Preview mode.... see your report. Print the report. You can only see the results in preview mode or when printed. There is a technique for pasting a "picture" of your report to a container field.... but that's for another time.

Ellen, Totally wierd.... did it to me when I was testing an answer for you. Windows XP with FM5.5. Anybody have an idea?