
toolUser
Members-
Posts
31 -
Joined
-
Last visited
Everything posted by toolUser
-
QuinTech said: "Yes, if you pass a field definition rather than text. Create a calc field which is equal to "cmd /c cscript c:wherevervbscript.vbs " & theIPAddress where theIPAddress is a global field that can be edited as necessary. " Thanks for the help. Some things still aren't clear to me, however. I suspect it's my unfamiliarity with FM. q1: How do you pass a field definition rather than text? I see a place to send a calculation, but that's not it, right? You mean a calc field in the table with the IP address, right? The other choices are to send a file or text. Do you point to the field def in the text box? How? q2: Why is IP address a Global field? Wouldn't it be the IP address in the current record? Or, do I misunderstand Global's? I thought they were essentially constants; same content in each record (actually a pointer to content, I suspect). Thanks, Jerry And sorry for being so obtuse...
-
Yes, vbscript takes an argument, thanks to WSH, but how do you get the argument out of FM? In the SendEvent function I don't see how you both run the script and give it an argument that represents, say, a field in the current record. Calling <cmd /c cscript c:wherevervbscript.vbs 192.169.1.88> is fine, but the IP address needs to be a variable. I suspect I'm just missing something, can you do it from a SendEvent calculation? Jerry
-
Yes, I can get FM7 to create the .rdp file with the correct IP inserted. Which I can use as an argument to remoteDesktop (mstsc.exe) which is run by a vbscript that tests to see if the remote computer is up, if someone is logged on, who that is, with the option of sending a request to log on, which blanks the screen. Sorry if my description was confusing, the .rdp file is the argument to mstsc.exe. What I wanted was an argument to a vbscript script (in this case an IP address) that would do the heavy lifting regarding building the .rdp and running mstsc. It may sound trivial, the difference between building the .rdp in vbscript vs FM, but vbscript is reasonably powerful and once you have the ability to pass an argument you can probably do a lot more with vbscript. So, I do have a solution to my problem, just not as elegant as I hoped. ----- Ted S has it exactly right. I think the ability to run a program (say, Traits.exe) outside FM and pass it an argumnent or two from specific FM fields in the current record ( /brown /caucasian) would be very elegant and useful. At least on a PC. Thanks for the help. Jerry
-
Ok, I suppose the silence means FM can't do exactly that. I can work around by simply recreating the .rdp file each time. Perhaps FM can solve this in the next round of development. I see it as a need, do others? Jerry
-
Sorry, you're right, I should have been more explicit. Here's what I'm doing: I administer a small network of about 350 PC's (and about 350 Macs, that I currently don't support directly, but I'll be going there), in an AD/OD domain in a university setting. I use vbscript, WMI, enterprise versions of anti virus, firewalls, anti spyware, etc. to scan, maintain, and support them and FM holds the database. My users (pretty much all faculty or grad students) are administrators on their computers (and psychologists...) - so they keep me hopping. The general problem is doing something on a remote computer from within FM. The thing I want to do now is to push a button in FM associated with a record (of a PC computer in this case) that runs a script that starts a RemoteDesktop session on the remote computer. This is sort of important to me as I've got some mobility issues. The vbscript takes an argument in the form of an IP address and puts it into a .rdp file (the file type that Microsoft's RemoteDesktop uses) the script then runs RemoteDestop to connect to that PC. I got it working using the clipboard, but there is an issue with Copy on my computer, and I don't think that's an elegant solution anyway. I want to use something like the SendEvent FM script function to run the RemoteDesktop script and pass it an argument. But it's not clear how to do that. Perhaps I simply don't understand the Send Text part of Send Event. And, yes I'm sort of new to FM. Thanks for the help, Jerry
-
I was trying to avoid creating and reading a file, must be something more elegant. Send Message sounds like the thing, but what is it? I've been using Send Event to run scripts for awhile, but I see no Send Mssage that would run a script and present it with an argument. I've been all over the help file and see no mention of running a script with an argument. Could you enlighten me? Thanks, Jerry
-
I thought I had a solution, pass via the clipboard, but I'm haveing a problem with the Copy function. How else would you pass the contents of the current field to a program outside of Filemaker, in this case vbscript? I'm putting it into a text field. Thanks, Jerry
-
Thanks. I've did a workaround, Entered "~"'s in all the empty fields... Well, they're pretty static, not many rooms morph in this building. Jerry
-
Ok, how would using the IsEmpty()function make the join work? Somehow use it in a script in the Define Database Relationships? I haven't seen that done. Jerry
-
In FM7 I have a join of four fields; building, floor, room, subroom. Why break out subroom? Well, I've gone back and forth on that, I wanted it because it makes an FM find unique. But joins seem to fail when there is no subroom. Apparently you can't join to an empty field. As: BUILDINGFIELD1::bld <> BUILDINGFIELD2::bld FLOORFIELD1::fl <> FLOORFIELD2::fl ROOMFIELD1::rm <> ROOMFIELD2::rm SUBROOM1::srm <> SUBROOM2::srm matches and joins table 1 to table 2. But: BUILDINGFIELD1::bld <> BUILDINGFIELD2::bld FLOORFIELD1::fl <> FLOORFIELD2::fl ROOMFIELD1::rm <> ROOMFIELD2::rm SUBROOM1:[empty] <> SUBROOM2::[empty] doesn't seem to match, the empty field problem. In most databases you can choose to consider an empty field as a null field, that is; it has no value, but is not empty, therefore: BUILDINGFIELD1::bld <> BUILDINGFIELD2::bld FLOORFIELD1::fl <> FLOORFIELD2::fl ROOMFIELD1::rm <> ROOMFIELD2::rm SUBROOM1::null <> SUBROOM2::null Would match. Which would solve my problem, I think, without rebuilding my tables. How can I get this to work in FM7? Thanks for any help. Jerry
-
-
Hi, I've had an issue with FM7 and FM7Dev on my Windows XP PC for a little while and now it's become a real problem. When I select field contents and copy, either by Ctrl C, menu Edit|Copy, right click|Copy, or by script, the copy randomly fails, leaving a null field in the clipboard. In other words, it writes over the previous clipboard contents with a null. I was gnashing my teeth and working around this for a while, but now I need to use the Copy function in a script. Something in the back of my mind says it may have something to do with Office and how it uses the clipboard. And, I have the fewest problems after a reboot, then it gets progressivly worse. Any ideas? Thanks, Jerry
-
Great! I think I see it. In any case it's happily importing the XML. Your code really helped me understand. Actually I think I can write a script that will create the XSLT, I'll pass it along when done. Jerry
-
Thanks, I appreciate that. especially Fenton going to all that trouble. You are right, DykstrL, it was generated from Microsoft's Office Inventory Convert.exe. Which is their product for interpreting a previous scan for Windows Office products updates. I'm using it to roll my own Office Updater and using FM to join the Updates table to the Computer info table. Having said that, I have no idea what would make it not a true XML file, aren't they simply text? Why do you think it's not. BTW, I cut and pasted text from the original, is that the problem? I can import it into Excel and export a text file, but, a. it's kluge and not very scriptable, and b. Importing it into Excel does some odd things, such as; it opens as three files. The file itself, book1, and book2. It looks like I am able to save the data correctly as text though. So, what the XSLT file is doing is converting the original XML to another XML file with the tags FM expects? I'll play with the your XSLT, Fenton. So, no XSLT converters out there? Jerry
-
Hi, I'm trying to import an XML file, snippet attached. It appears I need to create a XSLT file. I haven't messed with XML, so its not clear what I need to do. Here's the error I get on import: XML parsing error: Attribute 'EXPIRED' is not declared for element 'PATCH' Line Number: 2 Column Number: 405463 I assume that the fact that EXPIRED is not "declared" is due needing a style sheet. The table I'm trying to import into has fields for each attribute in the XML file. I've read some about XSLT files and it appears I need to include some formating info; file type etc. What do I need? I expected there might be some info in FM help - virtually nothing. I haven't been able to find any samples or templates. Are there examples of an XML file to be imported and its correct XSLT file? Given that the original file exists in a parsable file type, I'd think there would be a program or script that would create the XSLT from an XML. Do you know of any? Thanks, Jerry Sample.txt
-
Thanks.
-
Pro 7
-
Well, that's hard to believe. But, maybe so. I haven't been able to find any examples like that, can you either show yours or point me to some examples? Thanks, Jerry
-
This must easy given how common it is, I just don't see how. One of the most important things in a database is ensuring that the entered data is in the correct format. For example: I have two fields, IP address and MAC address. IP must be in the format of; [1-3 digits].[1-3 digits].[1-3 digits].[1-3 digits], like this 111.25.69.87 The "." must be a period, nothing else. MAC address must be [2 hex digits]:[2 hex digits]:[2 hex digits]:[2 hex digits]:[2 hex digits]:[2 hex digits], Like this 23:0a:8d:00:23:bc The seperator must be a colon and the alpha hex characters must be lowercase. Where does a template or whatever exist to enforce this? Thanks, Jerry
-
Thanks, Looked at the samples, but there seems to be a problem with each. The archived data all appears to exsist in the same table. If I have a table within which there is a key field where current data is in a one to one relationship, I can't also keep data that is one to many in that table. So I think I need a second table to to keep the one to manys. What i want to do is, during a scripted import, examine the current import record, determine if a concatenated foreign key (eg. Field1+Field2+Field3) for a given key is the same as the equivalent concatenated key in the exsisting record and, if not, write it to a one to many table. Thanks, Jerry
-
Thanks, will check them out. Jerry
-
Hi, This is probably really simple. When I import records to a table (Current_Table) that may or may not update certain fields, I want to have a copy of any records with those fields updated copied to another table (Archive_Table) before the record is changed. There are seven fields in the table; one key field, two that change on every update (Date and Time), don't want to archive those. When an update changes any of the four other fields I want to write the whole record to the Archive_Table, then update the record. I've thought of some very kluge ways to do this that involve archiving everything, but there must be an elegant technique out there. Thanks, Jerry
-
Hi, Just learning FM7. Situation; two tables in a database with a join on field1. I want to find the records in table1 that are not in table2. In SQL it might be something like this; SELECT * from table1:Field1 NOT IN table2:field1. Any ideas? Thanks, Jerry
-
multiple fields as unique keys
toolUser replied to toolUser's topic in Calculation Engine (Define Fields)
Ok, I see it now. Haven't quite got it implemented yet, the help file is not perfectly clear, but here is what it says: +++++++++++++++++++++++++++++++++++++++++++++++ Identifying duplicate values using a self-join relationship This procedure identifies "extra" instances of duplicated records. You specify the criteria that determine which is the primary record. This procedure uses a self-join relationship and a calculation field referencing the relationship to determine which records are duplicates. To find duplicate records except the first instance: 1.If you plan to delete the duplicate records that you find, make a backup copy of the file. For more information, see Saving and copying files. 2.Identify a field that determines a unique entity in your file. For example, in a Contacts database, the Last Name field is probably not a good choice, because you might have several people with the same last name. Social Security Number is a better choice. You can also create a calculation field (returning a text result) that combines data in several fields to make a unique identifier. An example formula is First Name & Last Name & Phone Number. 3.Define a self-join relationship. Use your chosen identifying field as the match field in both tables in the relationship. For more information, see About self-joining relationships. The primary record is the first matching record according to the sort order defined in the relationship. 4. Define two fields: Counter, a text field with an auto-entered serial number (select Serial number and accept the default values for Next and Increment by). Check Duplicates, a calculation field with a text result, with the formula: If(Counter = table1::Counter, "Unique", "Duplicate") 5.Choose Records menu > Show All Records. 6.Click the new Counter field, choose Records menu > Replace Field Contents, and Replace with serial numbers. Again, accept the default values. Select Update serial number in Entry Options, and click Replace. This will assign a serial number to all existing records in your database. Serial numbers will automatically be entered in new records. 7.Perform a find for Duplicate in the Check Duplicates field. The first record in any series of duplicates now holds the value "Unique" in the Check Duplicates field, and all duplicate records within the same series are marked "Duplicate". -
multiple fields as unique keys
toolUser replied to toolUser's topic in Calculation Engine (Define Fields)
Thanks, I'll play with it this week. Jerry