jackfeuer

I've recently discovered what appears to be a corruption problem within the schema in a major development project. What happens is this: In a Go To Related Record (GTRR) operation, "ghost" records appear; that is, non-existent, empty records. In the FM sidebar, the found count exceeds the total record count. For example, when executing a GTRR, I'll discover 49 "found" records out of a total 48 records in the table. The extra "record" is viewable (although all its fields are empty, including the relationship fields). I can also "delete" it through FM delete functions. However, when I do another GTRR, another ghost record appears. This error is associated with just one table. Any GTRRs that go to that table exhibit the problem. GTRRs to other tables work fine. I only recently noticed the error, but tracking back through daily backups, I can find the day in which the problem appears. One day the GTRR works fine for this table, the next day it does not. Something else of interest: The day the problem first appears coincides with a day that the app crashed and needed to be recovered. Note that I did NOT use the recovered file. I went back a day, got the backup, and re-did my work for the fatal day. So, even though the prior day's version of the app works fine, the corruption must have been latent in that version. It's now two weeks later, and I've got a lot of work to recreate. But even more troubling, I'm worried about how far back I need to go to ensure that the latent corruption isn't present. My best guess is that I'll go back several more days to the point where the troubled table was first added. If anybody has seen something similar (these "ghost" records in GTRRs), I'd be interested in hearing about the experience -- especially if you found a solution and/or determined that the issue was something other than a corrupt schema. And yes, I add my vote that I'd like the ability to export the schema as text that I could reimport.

A prior posting mentions that you can reduce the runtime size by eliminating some language files. That's accurate -- I think it will take 5 or 10 megs off the final size of the app. For detail on how to do that check the pdf documentation that ships with FM 7. Look for the document entitled "FMD 7 Developers Guide." In my copy, the relevant info starts on page 30. It's part of Chapter 4, "Distributing Runtime Database Solutions." The specific section is entitled "Choosing a Distribution Method" and the sub-section is "Reducing Solution Size".

These are both good alternatives, and I'll think some more about how to make them work in my specific situation. Each gives me some potential difficulties (see below), but I doubt that I'll find a perfect solution -- I have to balance the problems against giving up the "All" option. For globals there's a data entry speed and convenience issue: There could be a dozen or more portal records to enter for each parent record, and the portal's default "last row = new record" behavior is easier and faster than requiring a specific button-push to execute the script. I also have a real estate issue on this layout, which has 5 of these portals, all of which would require the additional global fields. For the calculated field, I'm concerned about the added size of the record from doubling up this value. Each record is very small, but there are hundreds of thousands (potentially millions) of them, and the calculated field would probably increase the size of this table by 1/3.

I am having a problem with a filtered portal in an app I'm developing. When a user creates a new record in this portal, FM over-writes the user-entered value in one of the fields (a field involved in the filter). I understand why it's happening, but I need to find a way to beat it, if I can. Here's the situation: I have a portal which users may filter by selecting a value from a pop up. That selected value is then used in the portal relationship to select only matching records. The pop up values are from a user-defined vocabulary, let's call them UserValue1, UserValue2, UserValue3, etc. I allow the user to select any one of those values or to select "All". If the user selects "UserValue1" only portal records containing that value will appear. If the user selects "All", all records will appear. Because the values are created by the user, I can't hardwire the relationship to any specific set of values. So I'm creating the relationship by converting the user's selected value into a range for purposes of the portal relationship. Thus, if the user selects UserValue1, the relationship selects a range from UserValue1 through UserValue1 -- which selects exactly the value the user requests. If the user selects "All", I select values from "a" to "zzzzzzzz" -- which accepts all values. This works fine for display, but it's given me a problem when the user creates a new record in the portal. When a new record is created, the user must specify a value in that new record for the field on which I am filtering. The user picks that value from a pop-up list. However, when the cursor hops to the next field in this new record, FM is replacing the user's selected value with the current "filter value". That is, if the portal is set to show "All" records, the user's selected value is replaced with "zzzzzzzz". If the user returns to the field, the "zzzzzzz" can be replaced with a valid value, and the valid value will "stick". Is there any way I can get the original value to stick in the first place?

Thanks, Bankmann, that seems to work -- cutting and pasting back. It stripped out the font, the color, and the size -- exactly what I was trying to do. Now it would be nice if FM just provided a text formatting function to strip this stuff (and I've therefore submitted it as an enhancement suggestion).

Maybe I'm doing something wrong, mlemmnapa, but this: TextStyleRemove ( TextColor ( text_field ; RGB ( 0 ; 0 ; 0 ) ) ; AllStyles) doesn't seem to solve the problem. It doesn't change the font or font size, and it doesn't strip the color, it simply changes it to black. I'm looking for something that strips all the pasted text characteristics and lets the data take the characteristics set in the field display definition. [color:"blue"] [color:"black"]

Yeah, I checked out "Synchronize with field's font", but that's for something else: According to FM Help: "Automatically set the input method to one that is appropriate for the script type of the font used in the field. (If an appropriate input method is not available, the input method does not change.) ... Input methods are software utilities that convert keystrokes to characters in another language such as Japanese."

I just loaded the 7.0v3 update, and one change in behavior is causing me problems: Data pasted into a field now retains text formatting (color, font, size) from the source document. In my app, one piece of data is typically copied and pasted by users from a variety of sources. That piece of data is then re-used (via text calculations) in a variety of other fields. Until I ran the update, each of those other fields could have its own display characteristics (color, font, size) set in the layout. Now, the portion of the data that has been pasted carries the text characteristics from the source. Thus, in the middle of several fields, I've now got data that is in a variety of colors, fonts, and sizes. Is there a way I can strip those characteristics away, so that the attributes of the display field control instead?

My requirement is simple, so I'm trying Reed's suggestion: substituting the Open URL step for the Send Mail step. After a handful of tests on the same records that were previously giving me errors, this seems to be working. Of course, the original problem didn't occur with perfect predictability, so it will be a while before I know for sure if it's gone. Thanks for the suggestion, Reed. And Fitch, thanks for the reassurance that I was at least not sending double emails to my clients.

I am using the email (Send Mail) script step attached to a button. Occasionally, the resulting email address is a "double" address, like this: <john.smith@smithcompany.com><john.smith@smithcompany.com> This happens irregularly. Almost always (but not every time) the problem occurs when the person's email address contains two dots as in the example above -- that is, it contains the usual dot in (dot)com plus one other. In the example above, the person's name is john(dot)smith. Or, in another case, the extra dot occurs in the company name, like this: johnsmith@ny.smithcompany.com. Rarely, this behavior also happens with a name that doesn't have a double-dot, and, equally rarely, a name that *does* have a double-dot works just fine. My original script contains some validation and uses a script parameter to supply the address. However, I've cut back to just the Send Mail step using the field directly, without a script paramenter, for testing. The same behavior occurs. I don't see anyone else reporting this problem in the forum. Has anyone else seen it. Am I doing something wrong?