All There has been a lot of talk lately on data bases, SVN's and don't look a gift horse in the mouth. I would like to make a suggestion. Even though we have a program that we can transfer data between the old and the new data bases, and I have MS Access and can do all kinds of things with it, it still is a pain to have to do. I have the memory filled with pages of frequencies that I use that needs to be transferred to the new data base. So why not separate the data base into two data bases, one that contains of frequencies and optional settings do not need to be updated with a new SVN, and one that does. Then the programmers will be happy and the rest of us will be happy too. A corollary to the updating of the data base is that PowerSDR is becoming much too complicated for the average ham to maintain. Think Flexradio, how this is going to affect your market.
Thank you Chas At 12:20 PM 1/8/2008, Jim Lux wrote: >At 08:26 AM 1/8/2008, [EMAIL PROTECTED] wrote: > >I think the implication in the posting was that there should perhaps be > >some kind of automated database upgrade that maybe runs at install > >and/or startup time and takes care of migration of various settings from > >the old schema to the new. This can quickly become non-trivial if there > >are multiple versions to consider (upgrade from what to what?). > > > >IMHO the lack of such a capability is not that big a problem due to the > >relatively small amount of inconvenience involved in occasionally > >manually recreating the database. > >And, we're really talking about database changes between bleeding >edge alpha releases. I think the existing database conversion >mechanisms work fairly well between actual production >releases. (that sort of reduces the scale of the "which version to >which version" complexity) > >That said, I wouldn't be surprised if some of the database >corruption/rebuild necessity has nothing to do with PowerSDR. The >Access/Jet DB engine has a number of odd quirks itself, and has lots >of little pieces that all have to work together, not to mention a >zillion versions of the MDB file internal structure. It isn't one of >Microsoft's finer products (which is why SQLServer is what they >recommend for "real" databases). > >See, e.g., http://allenbrowne.com/tips.html towards the bottom of the page. > > _______________________________________________ FlexRadio Systems Mailing List FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ Knowledge Base: http://kb.flex-radio.com/ Homepage: http://www.flex-radio.com/
