It appears to me that using <[M]> enables the interpretation of | as a conditional in the memo. One option would be to replace the | with \| in the memo to get what you want. On 7/29/19 9:16 PM, David Walker wrote: > It appears that my best option is to have the sentence structure for the Burial tag read as "[P] was buried <[D]> <[L]>”. In journal Report options I selected Memos Embedded. Having made those changes I get all text in the Memo field, including that comes after a pipe. In addition, I do not get the phrase “(an unknown value)” when there is no text in the Memo field. > > It appears that I inserted the expression <[M]> thinking it had to be there in order for text in the Memo field to be published. > > Thanks everyone for your input. > > Regards……David > >> On Jul 29, 2019, at 6:11 PM, Donald Range <[email protected]> wrote: >> >> Lee, >> The conditional markers applied to the [M] term in the sentence template seems to explain the difference in what you and I are seeing. I ran the below Cases 1) and 2) with the standard Burial tag, Cases 3) and 4) with my custom Burial-Memo tag, and Case 5) which removes the conditional markers from my custom Burial-Memo tag. >> >> I tested this by adding a temporary Burial tag to a person named Anne Elizabeth Range. The date and location fields were blank. In all cases below with the Burial tag memo contained: >> WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910 >> >> 1) With the Burial tag sentence template: >> [P] was buried <[D]> <[L]> >> And the Journal Report option set to Embed with parentheses, the Sentence Preview is: >> Anne Elizabeth Range was buried >> And the Journal Report output is: >> She was buried (WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910). >> >> 2) With the Burial tag sentence template: >> [P] was buried <[D]> <[L]> >> And the Journal Report option set to None, the Sentence Preview is: >> Anne Elizabeth Range was buried. >> And the Journal Report output is: >> She was buried. >> >> 3) With the Burial tag sentence template: >> [P] was buried <[D]> <[L]> <[M]> <. [M2]> >> And the Journal Report option set to Embed with parentheses, the Sentence Preview is: >> Anne Elizabeth Range was buried WALKER / Cecil Walker / 1847 - 1900. >> And the Journal Report output is: >> She was buried WALKER / Cecil Walker / 1847 - 1900. >> >> 4) With the Burial tag sentence template: >> [P] was buried <[D]> <[L]> <[M]> <. [M2]> >> And the Journal Report option set to None, the Sentence Preview is: >> Anne Elizabeth Range was buried WALKER / Cecil Walker / 1847 - 1900. >> And the Journal Report output is: >> She was buried WALKER / Cecil Walker / 1847 - 1900. >> >> 5) With the Burial tag sentence template: >> [P] was buried <[D]> <[L]> [M] <. [M2]> >> And the Journal Report option set to Embed with parentheses, the Sentence Preview is: >> Anne Elizabeth Range was buried WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910. >> And the Journal Report output is: >> She was buried WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910. >> >> So to summarize, Case 1) embeds the full memo, including the pipe. Cases 3) and 4), which include a conditional [M] term in the template, output only the text before the pipe as David reported. Case 5) which is the same as Case 3) except the [M] term has the conditional markers removed, duplicates what Lee and Michael saw with the full memo appearing in the output. >> >> On 7/29/2019 12:15 PM, Lee Hoffman wrote: >>> At 7/29/2019 13:42, Donald Range wrote >>>> It's likely that the reason that Lee and Michael don't see the same behavior as David is that they are using the standard Burial tag (which does not have a [M] term in the sentence template) and have their report options set to embed memos that are not included in the sentence. If one is using a Burial tag which does include the [M] term TMG works as David described with a single pipe, at least for me. >>> No, I used a number of different Tag Types -- the first was a Note Tag. I seldom use the Embed Memo option selected. Even so, the Embed Memo should show the full Memo entry in a report unless there is a valid set of vertical lines (pipes) to denotes a Split Memo. >>> >>> I also tried the Burial Tag. My Tag Sentence was: >>> [P] was buried <[D]> <[L]> "[M]" >>> and the result was as expected: >>> Hiram C. Wilson was buried in 1900 "WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910." >>> >>> What Tag Sentence did you use? >>> >>> Lee >>> >>> >>> _______________________________________________ >>> Email preferences: http://bit.ly/rootswebpref >>> Unsubscribe https://lists.rootsweb.com/postorius/lists/[email protected] >>> Privacy Statement: https://ancstry.me/2JWBOdY Terms and Conditions: https://ancstry.me/2HDBym9 >>> Rootsweb Blog: http://rootsweb.blog >>> RootsWeb is funded and supported by Ancestry.com and our loyal RootsWeb community >>> >> _______________________________________________ >> Email preferences: http://bit.ly/rootswebpref >> Unsubscribe https://lists.rootsweb.com/postorius/lists/[email protected] >> Privacy Statement: https://ancstry.me/2JWBOdY Terms and Conditions: https://ancstry.me/2HDBym9 >> Rootsweb Blog: http://rootsweb.blog >> RootsWeb is funded and supported by Ancestry.com and our loyal RootsWeb community > > > _______________________________________________ > Email preferences: http://bit.ly/rootswebpref > Unsubscribe https://lists.rootsweb.com/postorius/lists/[email protected] > Privacy Statement: https://ancstry.me/2JWBOdY Terms and Conditions: https://ancstry.me/2HDBym9 > Rootsweb Blog: http://rootsweb.blog > RootsWeb is funded and supported by Ancestry.com and our loyal RootsWeb community -- Richard Damon

It appears that my best option is to have the sentence structure for the Burial tag read as "[P] was buried <[D]> <[L]>”. In journal Report options I selected Memos Embedded. Having made those changes I get all text in the Memo field, including that comes after a pipe. In addition, I do not get the phrase “(an unknown value)” when there is no text in the Memo field. It appears that I inserted the expression <[M]> thinking it had to be there in order for text in the Memo field to be published. Thanks everyone for your input. Regards……David > On Jul 29, 2019, at 6:11 PM, Donald Range <[email protected]> wrote: > > Lee, > The conditional markers applied to the [M] term in the sentence template seems to explain the difference in what you and I are seeing. I ran the below Cases 1) and 2) with the standard Burial tag, Cases 3) and 4) with my custom Burial-Memo tag, and Case 5) which removes the conditional markers from my custom Burial-Memo tag. > > I tested this by adding a temporary Burial tag to a person named Anne Elizabeth Range. The date and location fields were blank. In all cases below with the Burial tag memo contained: > WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910 > > 1) With the Burial tag sentence template: > [P] was buried <[D]> <[L]> > And the Journal Report option set to Embed with parentheses, the Sentence Preview is: > Anne Elizabeth Range was buried > And the Journal Report output is: > She was buried (WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910). > > 2) With the Burial tag sentence template: > [P] was buried <[D]> <[L]> > And the Journal Report option set to None, the Sentence Preview is: > Anne Elizabeth Range was buried. > And the Journal Report output is: > She was buried. > > 3) With the Burial tag sentence template: > [P] was buried <[D]> <[L]> <[M]> <. [M2]> > And the Journal Report option set to Embed with parentheses, the Sentence Preview is: > Anne Elizabeth Range was buried WALKER / Cecil Walker / 1847 - 1900. > And the Journal Report output is: > She was buried WALKER / Cecil Walker / 1847 - 1900. > > 4) With the Burial tag sentence template: > [P] was buried <[D]> <[L]> <[M]> <. [M2]> > And the Journal Report option set to None, the Sentence Preview is: > Anne Elizabeth Range was buried WALKER / Cecil Walker / 1847 - 1900. > And the Journal Report output is: > She was buried WALKER / Cecil Walker / 1847 - 1900. > > 5) With the Burial tag sentence template: > [P] was buried <[D]> <[L]> [M] <. [M2]> > And the Journal Report option set to Embed with parentheses, the Sentence Preview is: > Anne Elizabeth Range was buried WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910. > And the Journal Report output is: > She was buried WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910. > > So to summarize, Case 1) embeds the full memo, including the pipe. Cases 3) and 4), which include a conditional [M] term in the template, output only the text before the pipe as David reported. Case 5) which is the same as Case 3) except the [M] term has the conditional markers removed, duplicates what Lee and Michael saw with the full memo appearing in the output. > > On 7/29/2019 12:15 PM, Lee Hoffman wrote: >> At 7/29/2019 13:42, Donald Range wrote >>> It's likely that the reason that Lee and Michael don't see the same behavior as David is that they are using the standard Burial tag (which does not have a [M] term in the sentence template) and have their report options set to embed memos that are not included in the sentence. If one is using a Burial tag which does include the [M] term TMG works as David described with a single pipe, at least for me. >> >> No, I used a number of different Tag Types -- the first was a Note Tag. I seldom use the Embed Memo option selected. Even so, the Embed Memo should show the full Memo entry in a report unless there is a valid set of vertical lines (pipes) to denotes a Split Memo. >> >> I also tried the Burial Tag. My Tag Sentence was: >> [P] was buried <[D]> <[L]> "[M]" >> and the result was as expected: >> Hiram C. Wilson was buried in 1900 "WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910." >> >> What Tag Sentence did you use? >> >> Lee >> >> >> _______________________________________________ >> Email preferences: http://bit.ly/rootswebpref >> Unsubscribe https://lists.rootsweb.com/postorius/lists/[email protected] >> Privacy Statement: https://ancstry.me/2JWBOdY Terms and Conditions: https://ancstry.me/2HDBym9 >> Rootsweb Blog: http://rootsweb.blog >> RootsWeb is funded and supported by Ancestry.com and our loyal RootsWeb community >> > > _______________________________________________ > Email preferences: http://bit.ly/rootswebpref > Unsubscribe https://lists.rootsweb.com/postorius/lists/[email protected] > Privacy Statement: https://ancstry.me/2JWBOdY Terms and Conditions: https://ancstry.me/2HDBym9 > Rootsweb Blog: http://rootsweb.blog > RootsWeb is funded and supported by Ancestry.com and our loyal RootsWeb community

Lee, The conditional markers applied to the [M] term in the sentence template seems to explain the difference in what you and I are seeing. I ran the below Cases 1) and 2) with the standard Burial tag, Cases 3) and 4) with my custom Burial-Memo tag, and Case 5) which removes the conditional markers from my custom Burial-Memo tag. I tested this by adding a temporary Burial tag to a person named Anne Elizabeth Range. The date and location fields were blank. In all cases below with the Burial tag memo contained:  WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910 1) With the Burial tag sentence template:  [P] was buried <[D]> <[L]> And the Journal Report option set to Embed with parentheses, the Sentence Preview is:  Anne Elizabeth Range was buried And the Journal Report output is:  She was buried (WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910). 2) With the Burial tag sentence template:  [P] was buried <[D]> <[L]> And the Journal Report option set to None, the Sentence Preview is:  Anne Elizabeth Range was buried. And the Journal Report output is:  She was buried. 3) With the Burial tag sentence template:  [P] was buried <[D]> <[L]> <[M]> <. [M2]> And the Journal Report option set to Embed with parentheses, the Sentence Preview is:  Anne Elizabeth Range was buried WALKER / Cecil Walker / 1847 - 1900. And the Journal Report output is:  She was buried WALKER / Cecil Walker / 1847 - 1900. 4) With the Burial tag sentence template:  [P] was buried <[D]> <[L]> <[M]> <. [M2]> And the Journal Report option set to None, the Sentence Preview is:  Anne Elizabeth Range was buried WALKER / Cecil Walker / 1847 - 1900. And the Journal Report output is:  She was buried WALKER / Cecil Walker / 1847 - 1900. 5) With the Burial tag sentence template:  [P] was buried <[D]> <[L]> [M] <. [M2]> And the Journal Report option set to Embed with parentheses, the Sentence Preview is:  Anne Elizabeth Range was buried WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910. And the Journal Report output is:  She was buried WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910. So to summarize, Case 1) embeds the full memo, including the pipe. Cases 3) and 4), which include a conditional [M] term in the template, output only the text before the pipe as David reported. Case 5) which is the same as Case 3) except the [M] term has the conditional markers removed, duplicates what Lee and Michael saw with the full memo appearing in the output. On 7/29/2019 12:15 PM, Lee Hoffman wrote: > At 7/29/2019 13:42, Donald Range wrote >> It's likely that the reason that Lee and Michael don't see the same >> behavior as David is that they are using the standard Burial tag >> (which does not have a [M] term in the sentence template) and have >> their report options set to embed memos that are not included in the >> sentence.  If one is using a Burial tag which does include the [M] >> term TMG works as David described with a single pipe, at least for me. > > No, I used a number of different Tag Types -- the first was a Note > Tag.  I seldom use the Embed Memo option  selected.  Even so, the > Embed Memo should show the full Memo entry in a report unless there is > a valid set of vertical lines (pipes) to denotes a Split Memo. > > I also tried the Burial Tag.  My Tag Sentence was: >    [P] was buried <[D]> <[L]> "[M]" > and the result was as expected: > Hiram C. Wilson was buried in 1900 "WALKER / Cecil Walker / 1847 - > 1900 | Sarah Smith / 1850 - 1910." > > What Tag Sentence did you use? > > Lee > > > _______________________________________________ > Email preferences: http://bit.ly/rootswebpref > Unsubscribe https://lists.rootsweb.com/postorius/lists/[email protected] > Privacy Statement: https://ancstry.me/2JWBOdY  Terms and Conditions: > https://ancstry.me/2HDBym9 > Rootsweb Blog: http://rootsweb.blog > RootsWeb is funded and supported by Ancestry.com and our loyal > RootsWeb community >

At 7/29/2019 13:42, Donald Range wrote >It's likely that the reason that Lee and Michael >don't see the same behavior as David is that >they are using the standard Burial tag (which >does not have a [M] term in the sentence >template) and have their report options set to >embed memos that are not included in the >sentence. If one is using a Burial tag which >does include the [M] term TMG works as David >described with a single pipe, at least for me. No, I used a number of different Tag Types -- the first was a Note Tag. I seldom use the Embed Memo option selected. Even so, the Embed Memo should show the full Memo entry in a report unless there is a valid set of vertical lines (pipes) to denotes a Split Memo. I also tried the Burial Tag. My Tag Sentence was: [P] was buried <[D]> <[L]> "[M]" and the result was as expected: Hiram C. Wilson was buried in 1900 "WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910." What Tag Sentence did you use? Lee

It's likely that the reason that Lee and Michael don't see the same behavior as David is that they are using the standard Burial tag (which does not have a [M] term in the sentence template) and have their report options set to embed memos that are not included in the sentence.  If one is using a Burial tag which does include the [M] term TMG works as David described with a single pipe, at least for me. On 7/29/2019 9:43 AM, Michael J. Hannah wrote: > Like Lee I tested having a single vertical bar in memo text.  Using > the memo variable [M] in the sentence I get the entire text output in > a Journal report with no problems.  Thus I also suspect you have *two* > vertical bars in a row with no space between and which are not escaped. > > TMG has a number of special characters which it uses for various > specific meanings in the data that is entered.  The vertical bar or > pipe character is one of these, and has meaning to TMG in memos.  Two > of those characters _in_a_row_ has a special meaning: the indicator of > split memo parts.  TMG documentation is clear that "if" there are > split memo parts then the sentence variable [M] will only output in > reports the _first_ split memo part.  That fits with what you describe > as your Journal output. > > I constructed a list in my book of all characters which have some > special meaning "somewhere" in TMG here: > > https://www.mjh-nm.net/DATENTRY.HTML#SpecialUseChars > > I recommend in the book that generally they should be escaped with the > TMG backslash '\' escape character to avoid their special meaning when > used within text.  As best I have been able to notice, there is no > disadvantage to escaping them in text even if not needed, and Second > Site will definately recognize the escape sequence. > > The simple solution is to put a space between any two vertical bars > which you desire to be treated as text.  However, if for some reason > you want to have two vertical bars in a row without a space, then > escape both characters like '\|\|'. > > Hope this helps explain, > > Michael

David Walker wrote: > ... I use pipes ‘|’ to separate sections of the inscriptions... > When creating a Journal report ... > It appears that the use of a pipe terminates the creation > of the memo field at that point. Hi David, Like Lee I tested having a single vertical bar in memo text. Using the memo variable [M] in the sentence I get the entire text output in a Journal report with no problems. Thus I also suspect you have *two* vertical bars in a row with no space between and which are not escaped. TMG has a number of special characters which it uses for various specific meanings in the data that is entered. The vertical bar or pipe character is one of these, and has meaning to TMG in memos. Two of those characters _in_a_row_ has a special meaning: the indicator of split memo parts. TMG documentation is clear that "if" there are split memo parts then the sentence variable [M] will only output in reports the _first_ split memo part. That fits with what you describe as your Journal output. I constructed a list in my book of all characters which have some special meaning "somewhere" in TMG here: https://www.mjh-nm.net/DATENTRY.HTML#SpecialUseChars I recommend in the book that generally they should be escaped with the TMG backslash '\' escape character to avoid their special meaning when used within text. As best I have been able to notice, there is no disadvantage to escaping them in text even if not needed, and Second Site will definately recognize the escape sequence. The simple solution is to put a space between any two vertical bars which you desire to be treated as text. However, if for some reason you want to have two vertical bars in a row without a space, then escape both characters like '\|\|'. Hope this helps explain, Michael

One vertical line is used within conditionals for various uses to vary the sentence on certain conditions like if the person is still living (to adjust tense) or if there is a second principal (to adjust to plural). It could well be that TMG has a bug that it doesn’t handle it right if it sees it elsewhere (while Second Site took more care to not treat it special where it isn’t defined to be special) > On Jul 29, 2019, at 12:22 PM, Lee Hoffman <[email protected]> wrote: > > At 7/29/2019 10:08, David Walker wrote >> When documenting tombstones in TMG v9.05 I use pipes (‘|’ to separate sections of the inscriptions. For instance, there could be husband’s name, below which are his birth & death dates. On the right side of the tombstone his wife’s inscription might read her name, below which are her birth & death dates. In the memo field of the burial tag I use a single pipe to illustrate that there are these two blocks of inscriptions. I also use a forward slash (‘/‘ to indicate next line. >> >> A typical example might be: WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910 >> >> When creating a Journal report all that shows is WALKER / Cecil Walker / 1847 - 1900. It appears that the use of a pipe terminates the creation of the memo field at that point. > > As Donald says, the vertical line character has special meaning in TMG. Two vertical lines (pipes) [e.g., "||" (no quotes)] is used to separate text when used in split fields as in Split Memos and Split Detail and other places. > > Your example shows just the one vertical line. I see no problem with that. Also, I do not see missing data using that entry when I try the Journal or other narrative report. Did you copy/paste the example or is there actually two vertical lines in your Tag Memo entry? > > See the TMG Help topic "Memo" and "Memo, Split" for more information about split fields. > > Lee > > _______________________________________________ > Email preferences: http://bit.ly/rootswebpref > Unsubscribe https://lists.rootsweb.com/postorius/lists/[email protected] > Privacy Statement: https://ancstry.me/2JWBOdY Terms and Conditions: https://ancstry.me/2HDBym9 > Rootsweb Blog: http://rootsweb.blog > RootsWeb is funded and supported by Ancestry.com and our loyal RootsWeb community

At 7/29/2019 10:08, David Walker wrote >When documenting tombstones in TMG v9.05 I use >pipes (‘|’ to separate sections of the >inscriptions. For instance, there could be >husband’s name, below which are his birth & >death dates. On the right side of the tombstone >his wife’s inscription might read her name, >below which are her birth & death dates. In the >memo field of the burial tag I use a single pipe >to illustrate that there are these two blocks of >inscriptions. I also use a forward slash (‘/‘ to indicate next line. > >A typical example might be: WALKER / Cecil >Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910 > >When creating a Journal report all that shows is >WALKER / Cecil Walker / 1847 - 1900. It appears >that the use of a pipe terminates the creation of the memo field at that point. As Donald says, the vertical line character has special meaning in TMG. Two vertical lines (pipes) [e.g., "||" (no quotes)] is used to separate text when used in split fields as in Split Memos and Split Detail and other places. Your example shows just the one vertical line. I see no problem with that. Also, I do not see missing data using that entry when I try the Journal or other narrative report. Did you copy/paste the example or is there actually two vertical lines in your Tag Memo entry? See the TMG Help topic "Memo" and "Memo, Split" for more information about split fields. Lee

The "pipe" is a character that has special meaning in TMG memos. To output the pipe literally you need to precede it with a backslash escape character (\|). This will cause the pipe and the text following it to be output in the journal report. An alternative is to use double pipes (||) as separators instead of single pipes. This will cause the text following the double pipe to be treated as the second memo segment [M2], and if you alter the burial tag sentence template to include <[M2]> the second part of the text will be output without showing the pipes. If you wished this would also allow you to include additional wording in these cases, such as "same stone" when [M2] is present. On 7/29/2019 7:08 AM, David Walker wrote: > When documenting tombstones in TMG v9.05 I use pipes (‘|’ to separate sections of the inscriptions. For instance, there could be husband’s name, below which are his birth & death dates. On the right side of the tombstone his wife’s inscription might read her name, below which are her birth & death dates. In the memo field of the burial tag I use a single pipe to illustrate that there are these two blocks of inscriptions. I also use a forward slash (‘/‘ to indicate next line. > > A typical example might be: WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910 > > When creating a Journal report all that shows is WALKER / Cecil Walker / 1847 - 1900. It appears that the use of a pipe terminates the creation of the memo field at that point. > > Second Site has no problem displaying the entire memo as entered. >

When documenting tombstones in TMG v9.05 I use pipes (‘|’ to separate sections of the inscriptions. For instance, there could be husband’s name, below which are his birth & death dates. On the right side of the tombstone his wife’s inscription might read her name, below which are her birth & death dates. In the memo field of the burial tag I use a single pipe to illustrate that there are these two blocks of inscriptions. I also use a forward slash (‘/‘ to indicate next line. A typical example might be: WALKER / Cecil Walker / 1847 - 1900 | Sarah Smith / 1850 - 1910 When creating a Journal report all that shows is WALKER / Cecil Walker / 1847 - 1900. It appears that the use of a pipe terminates the creation of the memo field at that point. Second Site has no problem displaying the entire memo as entered.

Terry, thanks for the suggestion. I had not thought of doing it that way, and did not realize that creating a new dataset or project would renumber everything. Sure prefer not to do that. Previously, when either copying or moving people from one dataset to another, I have had difficulting with TMG hanging at about 72% and then would have to abort and use Task Mgr to close TMG. Don't know what causes it, but it happens about 50% of the times when I try to copy or move people. Makes me hesitant, but I can try to copy them and then delete from main Project if it copies them all OK. I'll give it a try once again. Jim On Sat, Jul 27, 2019 at 12:13 PM Terry Reigel <[email protected]> wrote: > On 7/27/2019 12:39 PM, Jim Slade wrote: > > I have a Project from which I would like to remove about 150 people. > That > > is too many to delete individually, but I know that it can be done by > > setting a Delete Flag and then create a New Project including everyone > > whose Delete Flag is not equal Y. > > > > My question is: > > Would it be just as efficient to use the same method, but just create a > New > > DataSet rather than a New Project? > > Is there any downside to deleting by creating the DataSet rather than a > > Project? > > > Jim, > > I'd use a new Data Set, but go about it a bit differently. > > - Create a new empty Data Set. > > - Use the Delete Flag with a filter in the Project Explorer and Select > everyone. > > - Use the Move People command (Edit menu) to move the 150 people to the > new Data Set. > > - Delete that Data Set. > > I don't know of a downside to doing it that way. > > I believe that creating either a new Project or a new Data Set for the > "keepers" will renumber everything -- ID #s, Source #s, etc. which I'd > not want to do. > > Terry Reigel > > > > _______________________________________________ > Email preferences: http://bit.ly/rootswebpref > Unsubscribe https://lists.rootsweb.com/postorius/lists/[email protected] > Privacy Statement: https://ancstry.me/2JWBOdY Terms and Conditions: > https://ancstry.me/2HDBym9 > Rootsweb Blog: http://rootsweb.blog > RootsWeb is funded and supported by Ancestry.com and our loyal RootsWeb > community >

On 7/27/2019 12:39 PM, Jim Slade wrote: > I have a Project from which I would like to remove about 150 people. That > is too many to delete individually, but I know that it can be done by > setting a Delete Flag and then create a New Project including everyone > whose Delete Flag is not equal Y. > > My question is: > Would it be just as efficient to use the same method, but just create a New > DataSet rather than a New Project? > Is there any downside to deleting by creating the DataSet rather than a > Project? Jim, I'd use a new Data Set, but go about it a bit differently. - Create a new empty Data Set. - Use the Delete Flag with a filter in the Project Explorer and Select everyone. - Use the Move People command (Edit menu) to move the 150 people to the new Data Set. - Delete that Data Set. I don't know of a downside to doing it that way. I believe that creating either a new Project or a new Data Set for the "keepers" will renumber everything -- ID #s, Source #s, etc. which I'd not want to do. Terry Reigel

I have a Project from which I would like to remove about 150 people. That is too many to delete individually, but I know that it can be done by setting a Delete Flag and then create a New Project including everyone whose Delete Flag is not equal Y. My question is: Would it be just as efficient to use the same method, but just create a New DataSet rather than a New Project? Is there any downside to deleting by creating the DataSet rather than a Project? Jim

LAST IS FIXED. I eventually found that I had inadvertently changed the folder name of The Master Genealogist v9 under C:\ProgramData. It thus became inaccessible, and “Last” was grayed out, and my layouts and TMG help were not available. There were no doubt other anomalies and deficiencies that would have eventually surfaced if I had continued using TMG that way. I appreciate all the help and hints that kept me going and guided me to the solution. Regards, Bob Fleck

Bob Fleck updated: > I'm using my project files and updating fine, > but still have the Last problem. > Still looking Since you are still looking, Bob, you might consider this. As others have noted, the symptom appears to be that the app.ini file is not being updated when the program closes, as that is when the "Last" filename is written to that file. When TMG is running click on the Help main menu item, and in that submenu click on "Access Folders". As the program warns, while clicking on any folder name will open that folder and show its list of files, do not edit or alter any files in these folders while TMG is running. Look at the second line "User program data folder". That "Location" is the folder which contains the app.ini file being used by the program. Thus that is the folder to check whether that folder, and the files in that folder, have Windows permissions set to allow write/modify. Hope this helps, Michael

On 7/25/2019 11:16, John Cardinal wrote: > > I also just got back from a vacation to France. I am a fan of the Tour de France and my daughters treated my wife and I to a trip to see some of it. I decided to almost not work during the trip, a rarity for me. I usually work at least a few hours every day when I am on vacation, but I reduced that to about 20 minutes a day on this trip. I love what I do, but it felt good to set it aside (mostly!) for a few days. > John John I hope the heat that France is have now was not to bad when you were there. I know you love what you do because you produce great products and give great support to your users. Please take more time off for you and your family. Robert -- Robert Administrator of Clark County, MOGenWeb Project --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

I'm using my project files and updating fine, but still have the Last problem. Still looking: if I find out what the fix is I will let you know within this thread. Regards, Bob Fleck

John, you wrote:- "I also just got back from a vacation to France. I am a fan of the Tour de France and my daughters treated my wife and I to a trip to see some of it. I decided to almost not work during the trip, a rarity for me. I usually work at least a few hours every day when I am on vacation, but I reduced that to about 20 minutes a day on this trip. I love what I do, but it felt good to set it aside (mostly!) for a few days." Although, like all your other users, I am always keen to see the next development or improvement, I think you should adopt the above approach more often - "all work and no play...." and all that!

Pat Dunbar wrote: > I’m eagerly waiting your Gedcom release. Sadly, I’m too > old and too knackered to volunteer for beta-testing. > Here’s to a successful launch! Pat, I am getting close to a release of my "TMG-to-GEDCOM" program. The lack of beta testers is part of the reason the program is not available already. When I asked for volunteers, several people responded, and I thought I had what I needed. Unfortunately, most of the responders did not actually participate, and then several of the original beta testers got busy with other things. As a result, the beta test team is back to about where we started: four testers. Given the wide variety of requirements for the different targets (other genealogy programs as well as services like Ancestry.com), there is a lot of testing required, and fou8r testers isn't enough. However, adding testers requires some effort on my part, and when those testers don't actually test anything, I've wasted a lot of time. I'll be honest, it's very frustrating. I am very happy with the few people who are testing, I just wish there were more. I am not trying to pressure you or anyone else into volunteering, and even if people did volunteer now, I'd probably decline. Adding testers now would probably delay things. I'll continue to tweak things after the first release when users discover what's optimal. At this point, the program is producing the GEDCOM content that I expect but customizing options and making tweaks for the targets needs more work. That sort of thing is never complete, but I'd like to make some more progress. I also just got back from a vacation to France. I am a fan of the Tour de France and my daughters treated my wife and I to a trip to see some of it. I decided to almost not work during the trip, a rarity for me. I usually work at least a few hours every day when I am on vacation, but I reduced that to about 20 minutes a day on this trip. I love what I do, but it felt good to set it aside (mostly!) for a few days. John

At 7/24/2019 17:22, Dennis Lee Bieber wrote >At 05:10 PM 7/24/2019 -0300, John Cordes wrote: > > > My 3 main TMG data folders are in C:\ as follows: > > > > SharedProgramData > > UserData > > UserProgramData > > > > So... "C:\UserProgramData" then? > > > I just opened my TMG for the first time in 'quite a while' (over > >a week). Using the program Search Everything shows that the > >app.ini file with the current time stamp is located in > > > > C:\TMG\UserProgramData\ > > That doesn't agree with what you stated previously -- where > "UserProgramData" was stated to be in "C:\" > > I also have to wonder how TMG is FINDING that app.ini file. The > normal location used by TMG for the app.ini file should be in the > USER-SPECIFIC application-data directory (which is a hidden > directory by default, tied to the environment variable %appdata% -- > though one of the first things I do with my accounts is to either > change it to non-hidden or set Windows to show all hidden > files/directories). TMG needs a fixed/known location for the > app.ini in order to then find recently used projects (projects can > be anywhere that is read/write by the user). If a TMG installation is made to other than the default standard paths, then the three data folders (Shared Program Data, User Program Data, and User Data) have to be defined in the Data Paths.txt file that the user must create and place in the "The Master Genealogist v9" program folder. Note that this folder is in a restricted area, so the placement must be done by a user with Administrator privileges. When TMG is started after this, it creates (unless they are already created), populates, and uses those as if they were normally placed/created. The instructions for creating the DataPaths.txt file may be found in the TMG Help topic "Customizing Data File Storage". Lee