Did you run the other Database tools also? Test database integrity and then Rebuild indexes? Will a full gedcom complete? If so, import the gedcom into a new database and see if you get the same error message. * From:* Suzanne Brayer <sybrayer@gmail.com> *Subject:* Re: [RMagic] Error 26 message *Date:* Thu, 27 Dec 2012 21:17:46 -0700 *References:* < CAMrB1sq1P_EpZ7KBYyZ4MWFudwe2Pykk21CHrCWKmZqbt5ZMEQ@mail.gmail.com ><2B9F097C56154EAA8C38133ED13DF16B@toshiba> *In-Reply-To:* <2B9F097C56154EAA8C38133ED13DF16B@toshiba> Thanks, Tom for your help. I have tried to follow your suggestions. First, I compacted in RM, then I defragged and cleaned up. Finally I did a CHKDSK. When I open RM I still get the error message.Unless anyone has any other suggestions, I suppose I need to call in some professional help. Suzanne

Thanks, Tom for your help. I have tried to follow your suggestions. First, I compacted in RM, then I defragged and cleaned up. Finally I did a CHKDSK. When I open RM I still get the error message.Unless anyone has any other suggestions, I suppose I need to call in some professional help. Suzanne On Thu, Dec 27, 2012 at 11:09 AM, Tom Holden <ve3meo@gmail.com> wrote: > The SQLite Error 26 definition is "File opened that is not a database > file". > I would have thought that would be fatal and am surprised that you are able > to keep on working on the database. Is it possible that you had two > databases open the last time you closed RM and that you have been changing > the names of databases, possibly naming a file the same as one of the ones > open in the last session and that it is not a RootsMagic database but > something else, e.g., if you changed the extension to .rmgc, RM thinks it > is > a RM database file until it opens it and its database engine (SQLite3) > determines that it is not a SQLite3 database. Is this a recurring problem > with the same database file but not others? If so, then it sounds like your > database file has suffered some corruption which you might be able to > recover from by using RM's File > Database Tools, especially Compact which > should rewrite the database file in its entirety. If there was corruption, > it might be caused by one of two things: a power glitch during a write > operation or some degradation of your hard disc drive. In the case of the > latter, that may give you grief again, not necessarily with RootsMagic. You > would be wise to run the Windows Error-checking tool CHKDSK. > > Tom > > -----Original Message----- > From: Suzanne Brayer > Sent: Thursday, December 27, 2012 12:21 PM > To: rootsmagic-users@rootsweb.com ; sybrayer@gmail.com > Subject: [RMagic] Error 26 message > > When I open RM ver 6 I am getting a SQLite error 26 message. What is the > trouble? Once I close the error message window, I am able to work in the > system. > > > =================================== > RM list Archives: http://archiver.rootsweb.com/th/index/ROOTSMAGIC-USERS/ > http://archiver.rootsweb.com/cgi-bin/search?path=ROOTSMAGIC-USERS > WISH LIST: http://www.rootsmagic.com/forums/ BLOG: > http://blog.rootsmagic.com/ > > > ------------------------------- > To unsubscribe from the list, please send an email to > ROOTSMAGIC-USERS-request@rootsweb.com with the word 'unsubscribe' without > the quotes in the subject and the body of the message > > > > =================================== > RM list Archives: http://archiver.rootsweb.com/th/index/ROOTSMAGIC-USERS/ > http://archiver.rootsweb.com/cgi-bin/search?path=ROOTSMAGIC-USERS > WISH LIST: http://www.rootsmagic.com/forums/ BLOG: > http://blog.rootsmagic.com/ > > > ------------------------------- > To unsubscribe from the list, please send an email to > ROOTSMAGIC-USERS-request@rootsweb.com with the word 'unsubscribe' without > the quotes in the subject and the body of the message >

RM may be trying to open more than one data file. Try clearing the Program settings and customizations you've made; you will need to re-set your options and indicate the correct data file afterwards. From the main RM screen, press CTRL+SHIFT+U and choose the first option. > /From:/Suzanne Brayer <sybrayer@gmail.com <mailto:sybrayer@gmail.com>> > /Subject:/[RMagic] Error 26 message > /Date:/Thu, 27 Dec 2012 10:21:26 -0700 > > > When I open RM ver 6 I am getting a SQLite error 26 message. What is the > trouble? Once I close the error message window, I am able to work in the > system.

I agree with Jerry. Bruce's time would be better spent adding new features and fixes rather than fixing something that has a very adequate "workaround". I regularly use the sort date to re-organise my events. Steve -----Original Message----- From: rootsmagic-users-bounces@rootsweb.com [mailto:rootsmagic-users-bounces@rootsweb.com] On Behalf Of Jerry Bryan Sent: 27 December 2012 20:06 To: rootsmagic-users@rootsweb.com Subject: Re: [RMagic] RootsMagic 6 - sorting of birth, death and burial events when all occur in the same year > I would rather see Bruce continue to use his time to provide us with > new capabilities like he has been doing than "fix" a problem that is > easily handled by the program as it now stands. It's easily handled by the user as it now stands. It's not handled at all by the program as it now stands. Big difference. Jerry =================================== RM list Archives: http://archiver.rootsweb.com/th/index/ROOTSMAGIC-USERS/ http://archiver.rootsweb.com/cgi-bin/search?path=ROOTSMAGIC-USERS WISH LIST: http://www.rootsmagic.com/forums/ BLOG: http://blog.rootsmagic.com/ ------------------------------- To unsubscribe from the list, please send an email to ROOTSMAGIC-USERS-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

Lynn, I sent this to the list 3 hours ago. Did you miss it? "That's why subject lines are so important, so that list subscribers can quickly delete messages without reading them if they aren't interested in the topic being discussed. So long as everyone remains cordial and at least the barest minimum of new material is being presented, the discussion can continue. However, if the discussion devolves into nothing more than a rehash of what has been already said, and people who have already expressed their position simply keep posting it and re-posting it, I'll put an end to it. Anyone who has a problem with the discussion should email me directly, rather than expressing their displeasure on the list itself." Drew Smith RootsMagic-Users List Administrator On Thu, Dec 27, 2012 at 6:56 PM, LB <lingbro@family-quest.com> wrote: > Could we get off this sorting debate? There are others asking questions > and I would like to read responses to their questions, too. > > Lynn B.

I think my original post got lost in the l-o-n-g discussion about sort dates, so I am reposting it. From: "Yvonne Scott" <scottlass@triad.rr.com> Subject: [RMagic] Publish Online Date: Tue, 25 Dec 2012 18:21:10 -0500 I am playing around with the Publish Online feature in RootsMagic 6. I previewed a website I created, and the picture I used appears at the bottom of the home page. I prefer the picture at the top, under the heading. Could someone please tell me if there is a way to change the placement of the picture? Thanks, Yvonne

Could we get off this sorting debate? There are others asking questions and I would like to read responses to their questions, too. Lynn B.

That's why subject lines are so important, so that list subscribers can quickly delete messages without reading them if they aren't interested in the topic being discussed. So long as everyone remains cordial and at least the barest minimum of new material is being presented, the discussion can continue. However, if the discussion devolves into nothing more than a rehash of what has been already said, and people who have already expressed their position simply keep posting it and re-posting it, I'll put an end to it. Anyone who has a problem with the discussion should email me directly, rather than expressing their displeasure on the list itself. Drew Smith RootsMagic-Users List Administrator On Thu, Dec 27, 2012 at 3:19 PM, Randy Clark <ceddacosco@gmail.com> wrote: > I can't stand seeing any more messages on this topic arrive. There must be > 50 on a relatively trivial issue.

On Thu, Dec 27, 2012 at 3:18 PM, Jerry Bryan <c24m48@hotmail.com> wrote: > Those of us who care about this so > much believe that the natural ordering should be used in the case of same > sort date events that have a natural ordering. > Regardless of the order that "same-day" Birth, Death & Burial facts appear in the program screens or reports, there is never any confusion about the actual sequence of events on that day. Even five year-olds can figure it out ;-) -- -- -- --Ô¿Ô-- K e V i N

Amen - couldn't agree more. Ron Bernier Woonsocket, RI -----Original Message----- From: rootsmagic-users-bounces@rootsweb.com [mailto:rootsmagic-users-bounces@rootsweb.com] On Behalf Of Red Fenton Sent: Thursday, December 27, 2012 10:06 AM To: rootsmagic-users@rootsweb.com Subject: Re: [RMagic] RootsMagic 6 - sorting of birth, death and burial events when all occur in the same year I just don't see this being the big issue that people are making it.  I just have never found it to be a problem so I wrote a small program to find where I had the same date for birth and baptism, birth and death, or death and burial; It turns out to be in less than one half of one percent of the total number of fact entries in my database.  On those rare occasions when they might be the same I use the sort date or the more common case for me is where I pick up the Death Date from a tombstone I enter the death date as that on the tombstone and the burial date as being AFT the death date.   Doing it at the time of data entry takes no time at all.  I would rather see Bruce continue to use his time to provide us with new capabilities like he has been doing than "fix" a problem that is easily handled by the program as it now stands.  ----- Original Message ---- From: George W. Durman <GermannaResearch@comcast.net> To: rootsmagic-users@rootsweb.com Sent: Thu, December 27, 2012 12:00:57 AM Subject: Re: [RMagic] RootsMagic 6 - sorting of birth, death and burial events when all occur in the same year I'm almost ignorant on this subject, but how difficult would it be for those who write the code for RootsMagic to make the program sort by EVENT, i.e., Birth, Christening, Marriage, Death, Burial, etc., regardless of the date? FTM does that automatically, Birth comes before Marriage, Marriage comes before Death, Death comes before Burial, etc. Is it so difficult to sort by logical Events?  Doesn't seem to be an insurmountable problem, just takes common sense. If Birth, Death, and Burial all happen in the same year, why can't RM automatically align the events to show a logical progression? Sarge Germanna Database at Ancestry: http://trees.ancestry.com/tree/28427876/family My Germanna Database at Rootsweb: http://wc.rootsweb.ancestry.com/cgi-bin/igm.cgi?db=germanna My Germanna Website at Rootsweb: http://homepages.rootsweb.ancestry.com/~george/index.html =================================== RM list Archives: http://archiver.rootsweb.com/th/index/ROOTSMAGIC-USERS/ http://archiver.rootsweb.com/cgi-bin/search?path=ROOTSMAGIC-USERS WISH LIST: http://www.rootsmagic.com/forums/  BLOG: http://blog.rootsmagic.com/ ------------------------------- To unsubscribe from the list, please send an email to ROOTSMAGIC-USERS-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message =================================== RM list Archives: http://archiver.rootsweb.com/th/index/ROOTSMAGIC-USERS/ http://archiver.rootsweb.com/cgi-bin/search?path=ROOTSMAGIC-USERS WISH LIST: http://www.rootsmagic.com/forums/ BLOG: http://blog.rootsmagic.com/ ------------------------------- To unsubscribe from the list, please send an email to ROOTSMAGIC-USERS-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message

Jesse, thanks for the suggestion, a report is worth 100 words, maybe even 1000! One very simple example: ---------Individual Summary--------- Name: Birth Death *ORDER-1189 Sex: Unknown Individual Facts Death 1900 (about age 0) 3 Birth 1900 4 -------------------------------------------- The 3 and 4 are the Place Names for the 3rd and 4th events entered, and, as you can see, presented in the order they were entered, unnaturally and illogically. Please also view the Before and After images at http://sqlitetoolsforrootsmagic.wikispaces.com/Dates+-+Same+Day+Sort+Order . The Before image represents what you get after a GEDCOM import the way RM works now. The After image represents what an enhanced RM could present, regardless of what mechanism is used as a tie-breaker or default natural sort order; the reports would have the exact same order. Tom -----Original Message----- From: Jesse Davis Sent: Thursday, December 27, 2012 2:39 PM To: rootsmagic-users@rootsweb.com Subject: Re: [RMagic] RootsMagic 6 - sorting of birth, death and burial events when all occur in the same year Maybe it would help if we could have some ACTUAL examples of small reports that have not been handled the way you wish? Jess Davis

I can't stand seeing any more messages on this topic arrive. There must be 50 on a relatively trivial issue. On Thu, Dec 27, 2012 at 3:18 PM, Jerry Bryan <c24m48@hotmail.com> wrote: > > Whilst this discussion has centred around BMD events it is also an issue > > for > > any event type where there are multiple events on the same date, ie > > census, > > residence & occupation. Unless explicit sort dates are used these three > > events will occur in random order every time they are displayed. > > Totally correct. The difference is there is no natural ordering for census, > residence, and occupation. If you have census 1900, residence 1900, and > occupation 1900, then the order will be random unless the user includes a > sort date. It's really up to the user to include sort dates if desired. But > BMD events do have a natural ordering. Those of us who care about this so > much believe that the natural ordering should be used in the case of same > sort date events that have a natural ordering. > > Jerry > > > > > =================================== > RM list Archives: http://archiver.rootsweb.com/th/index/ROOTSMAGIC-USERS/ > http://archiver.rootsweb.com/cgi-bin/search?path=ROOTSMAGIC-USERS > WISH LIST: http://www.rootsmagic.com/forums/ BLOG: > http://blog.rootsmagic.com/ > > > ------------------------------- > To unsubscribe from the list, please send an email to > ROOTSMAGIC-USERS-request@rootsweb.com with the word 'unsubscribe' without > the quotes in the subject and the body of the message >

> Whilst this discussion has centred around BMD events it is also an issue > for > any event type where there are multiple events on the same date, ie > census, > residence & occupation. Unless explicit sort dates are used these three > events will occur in random order every time they are displayed. Totally correct. The difference is there is no natural ordering for census, residence, and occupation. If you have census 1900, residence 1900, and occupation 1900, then the order will be random unless the user includes a sort date. It's really up to the user to include sort dates if desired. But BMD events do have a natural ordering. Those of us who care about this so much believe that the natural ordering should be used in the case of same sort date events that have a natural ordering. Jerry

> What would be the facts with the same sort date in the wrong order? death 1900 (sort date 1900, which is the default sort date for a death date of 1900) birth 1900 (sort date 1900, which is the default sort date for a birth date of 1900) Jerry

> I would rather see Bruce continue to use his time > to provide us with new capabilities like he has been doing than "fix" a > problem > that is easily handled by the program as it now stands. It's easily handled by the user as it now stands. It's not handled at all by the program as it now stands. Big difference. Jerry

What would be the facts with the same sort date in the wrong order? From: Jerry Bryan Sent: Thursday, December 27, 2012 2:58 PM To: rootsmagic-users@rootsweb.com Subject: Re: [RMagic] RootsMagic 6 - sorting of birth,death and burial events when all occur in the same year > And it may flip order between the Event Save and the next time the Edit > Person screen is opened, IIRC. So that, too, should be resolved with > unique > SortDates for 'natural' events on the same date. I see this all the time. I call this facts "jumping around". So even when facts with the same sort date are in the right order, the right order can unexpectedly change into the wrong order. Jerry =================================== RM list Archives: http://archiver.rootsweb.com/th/index/ROOTSMAGIC-USERS/ http://archiver.rootsweb.com/cgi-bin/search?path=ROOTSMAGIC-USERS WISH LIST: http://www.rootsmagic.com/forums/ BLOG: http://blog.rootsmagic.com/ ------------------------------- To unsubscribe from the list, please send an email to ROOTSMAGIC-USERS-request@rootsweb.com with the word 'unsubscribe' without the quotes in the subject and the body of the message ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2637/5989 - Release Date: 12/26/12

> I'm almost ignorant on this subject, but how difficult would it be for > those > who write the code for RootsMagic to make the program sort by EVENT, > i.e., Birth, Christening, Marriage, Death, Burial, etc., regardless of the > date? The "regardless of date" is the part that many users don't want. It's one thing for a birth in 1900 to come before a death in 1900. That's ok, and it's way better than a death in 1900 coming before a birth in 1900. It's another thing altogether for a birth in 1901 to come before a death in 1900. The latter case is an error that the user should deal with. The program should not move a birth in 1901 in front of death in 1900, or at least a lot of users don't think it should. Jerry

> And it may flip order between the Event Save and the next time the Edit > Person screen is opened, IIRC. So that, too, should be resolved with > unique > SortDates for 'natural' events on the same date. I see this all the time. I call this facts "jumping around". So even when facts with the same sort date are in the right order, the right order can unexpectedly change into the wrong order. Jerry

> There would be no degradation in the detectability of typo errors with the > enhancement I propose to the auto-generation of the SortDate on Date > entry, Date edit, and GEDCOM import > that would resolve the current disordering of same-date events such as > Birth and Death. I seldom disagree with Tom, but I'm going to disagree ever so slightly on this one. I do agree that the problem can be addressed without any degradation to the detectability of typo errors. I also think the problem can be addressed without causing any harm whatsoever to the way users operate who prefer to insert their own sort dates. The misunderstanding is that when some of us talk about putting things like birth/death/burial in proper order, most of us do not mean that it would be unconditional. For example, if you had two birth facts with dates of 1899 and 1901 and a death fact with a date of 1900, then the facts should appear as follows. birth 1899 death 1900 birth 1901 Obviously, something is wrong with this data, but I'm certainly not proposing that by default the facts should appear as follows. birth 1899 birth 1901 death 1900 To do so would be to put 1901 before 1900, and that shouldn't happen by default no matter that a birth fact should precede a death fact if the data is correct. I'm simply saying that the following should not happen by default. death 1900 (with a sort date of 1900 as provided automatically by RM) birth 1900 (with a sort date of 1900 as provided automatically by RM) Instead, the following should happen by default. birth 1900 (with a sort date of 1900 as provided automatically by RM) death 1900 (with a sort date of 1900 as provided automatically by RM) The place where I disagree slightly with Tom is that I think the above could and should be accomplished without the program itself making any changes to the sort date. In other words, I don't think the following is necessary. birth 1900 (with a sort date of 1900-1 as provided automatically by RM) death 1900 (with a sort date of 1900-5 as provided automatically by RM) I can see how users who prefer to insert their own sort dates might be upset if RM inserted sort dates such as 1900-1 or 1900-5 automatically. Also, I think that the following should not happen by default. death (without a death date or a death sort date) birth (without a birth date or a birth sort date) Rather, the following should happen by default birth (without a birth date or a birth sort date) death (without a death date or a death sort date) And a text date with a default blank sort date should be treated exactly like a blank date with a blank sort date. It seems to me that if it was done this way - as a tie breaker only operating behind the scenes as a part of the sort of the facts, without any automatic sort date changing at all, and totally honoring any and all sort dates entered by the user - that everybody should be happy and that there shouldn't need to be an option to enable or disable this new automatic sorting feature. Sorts use tie breakers all the time. Why not RM when it is sorting an individual's facts? And a tie would be when a sort date for one fact exactly matches a sort date for another fact, or when a sort date for one fact is blank and the sort date for another fact is blank. Jerry

Maybe it would help if we could have some ACTUAL examples of small reports that have not been handled the way you wish? Jess Davis From: Tom Holden Sent: Thursday, December 27, 2012 2:33 PM To: rootsmagic-users@rootsweb.com Subject: Re: [RMagic] RootsMagic 6 - sorting of birth,death and burial events when all occur in the same year And what baffles me is the amount of time spent explaining to people how to fix something using Sort Dates that the program could do itself, without taking away anything from the power you have to change things to suit your own special cases. The "problem" is exported to reports: I failed to explain clearly that the 'natural' order for the 3rd and 4th events entered (being a Death and Birth respectively) was 43, not 34 as they came out in the reports.