Re: [sqlite] Incompatible versions of SQLite on same system
Joe, Thanks for the idea, but after a quick look at the ILDASM tool, I think it's beyond what I want to do to fix this problem (unlike the Dependency Walker tool, which I gave a spin). I guess I'll just have to wait for the HP and/or Intuit developers to solve the problem of incompatible SQLite versions. Thanks to everyone in the group who tried to help. Regards, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Joe Mistachkin To: 'General Discussion of SQLite Database' Date: Thu Jan 26 2012 23:52:00 GMT-0600 (Central Standard Time) In order to see which managed assemblies a .NET-based application will require, you'll need to use the ILDASM tool from the .NET SDK: http://msdn.microsoft.com/en-us/library/f7dy01k1%28v=vs.80%29.aspx -- Joe Mistachkin ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Incompatible versions of SQLite on same system
I don't have access to the machine with HP Connection Manager on it, but I just ran Dependency Walker on the TurboTax 2010 executable on a W7/64-bit machine, which is the same OS as on the other box, and DW showed no entries in the module list with in the name of the module. Does this make sense? Thanks, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Black, Michael (IS) To: General Discussion of SQLite Database Date: Wed Jan 25 2012 07:25:52 GMT-0600 (Central Standard Time) Try this utility on both programs and find out what DLL they are actually going for. And remember that if the DLL is already loaded it will use that. http://www.dependencywalker.com/ Michael D. Black Senior Scientist Advanced Analytics Directorate Advanced GEOINT Solutions Operating Unit Northrop Grumman Information Systems ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Incompatible versions of SQLite on same system
Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: epank...@comcast.net To: General Discussion of SQLite Database Date: Tue Jan 24 2012 15:24:00 GMT-0600 (Central Standard Time) 1. Could we please stay on topic How to post properly in the group is an important topic, especially for newbies. 2. Could we please not go down this road again? Why not? The archives are just that – archives. Perhaps there are some interesting new ideas on the subject. That said, I'll take a look at the archives. If you guys really want to argue about proper posting etiquette and / or using something besides an email list, they've both been done to death. Just search the archives or start a new thread that's appropriately titled. Just leave it out of this one. Eric ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Incompatible versions of SQLite on same system
Normand, I participate in many Google and Yahoo Groups (and am an Owner, Moderator, or Manager of several), and while their web interfaces are decent, I still prefer to receive posts in my email client, for many reasons. The most important reason is search, which, strangely enough, is mediocre in Google Groups, but on my local machine is terrific, because I run a top-quality search package that indexes everything in the wee hours and provides robust searching options. Also, the delete key in my email client works great. :) I do participate in some forums that provide an excellent web experience, such as Experts Exchange, but those are professional, custom-brew sites that were likely very expensive to build. Regards, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Normand Mongeau To: General Discussion of SQLite Database Date: Tue Jan 24 2012 15:19:16 GMT-0600 (Central Standard Time) On 2012-01-24 16:09, Tim Streater wrote: On 24 Jan 2012 at 20:02, Joe Winograd wrote: Thanks for the idea, but it will not install. The way this group operates with excessive trimming/snipping ... No it doesn't. It doesn't do *enough* trimming and snipping, and as a result our inboxes grow exponentially. If I want to read a thread I can sort by subject and then read it through. But this is made harder by the excessive repetition due to inadequate trimming (particularly of .sigs). -- Cheers -- Tim Did you guys ever consider Google Groups or something of the like? Email lists are soo clumsy. Normand ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Incompatible versions of SQLite on same system
Tim, I disagree completely. It is a rare individual who will read through all of the back threads to get a handle on an issue, whereas if it were all there in a single message, the person might read it, get up to speed, and jump in. As far as your inbox growing, that's easily handled with the delete key. Regards, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Tim Streater To: General Discussion of SQLite Database Date: Tue Jan 24 2012 15:09:00 GMT-0600 (Central Standard Time) On 24 Jan 2012 at 20:02, Joe Winograd wrote: Thanks for the idea, but it will not install. The way this group operates with excessive trimming/snipping ... No it doesn't. It doesn't do *enough* trimming and snipping, and as a result our inboxes grow exponentially. If I want to read a thread I can sort by subject and then read it through. But this is made harder by the excessive repetition due to inadequate trimming (particularly of .sigs). -- Cheers -- Tim ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Incompatible versions of SQLite on same system
Michael, That is one very cool utility! As soon as I can get access to the machine, I'll give it a spin. Thanks for the tip. Regards, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Black, Michael (IS) To: General Discussion of SQLite Database Date: Wed Jan 25 2012 07:25:52 GMT-0600 (Central Standard Time) Try this utility on both programs and find out what DLL they are actually going for. And remember that if the DLL is already loaded it will use that. http://www.dependencywalker.com/ Michael D. Black Senior Scientist Advanced Analytics Directorate Advanced GEOINT Solutions Operating Unit Northrop Grumman Information Systems ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Incompatible versions of SQLite on same system
> you can go ahead and reinstall HP's Connection Manager Kevin, Thanks for the idea, but it will not install. The way this group operates with excessive trimming/snipping, that has long since been removed from this thread (this M.O. makes it very difficult for a member to join a discussion in the middle), but here's what I wrote at the get-go: I received the following dialog box with the title : Cannot load assembly: System.Data.SQLite, Version=1.0.61.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139 The application will now exit. The supposed "answer" from HP is that you may use use either TurboTax or Connection Manager, but not both! I was hoping the experts in this forum would have a solution to this problem, or at least a better work-around than uninstalling one and reinstalling the other each time I need one of the programs. One of the really interesting things that came out in this thread (also long since trimmed) is that there is no SQLite DLL of any kind in the TurboTax directory structure and there doesn't seem to be one in any common/shared area that TT would be using (there *is* one in <\Common Files\Apple>, but TT is surely not using that). Also trimmed from earlier in the thread: I downloaded the latest from the link that Richard provided and replaced the copy in Connection Manager>. Running CM fails in the same way as previously reported and running (which is in the same directory as the CM executable and the new ) also fails in the same way as previously reported. Regards, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Kevin Benson To: General Discussion of SQLite Database Date: Tue Jan 24 2012 13:38:24 GMT-0600 (Central Standard Time) On Tue, Jan 24, 2012 at 11:32 AM, Joe Winograd wrote: Joe, Good to know! I had been looking just for. I don't have access to the machine right now, but I do have a clone of its system drive, and a search for turned up: System.Data.SQLite.Linq.DLL (more than one copy) System.Data.SQLite.DLL (more than one copy) System.Data.SQLite64.DLL (probably because it's 64-bit W7) At the time the clone was made, HP Connection Manager wasn't on it, but HP Power Assistant was, and the latter's directory in Program Files contains both and, so there's a good chance that HP Connection Manager will have those, too (I am not willing to uninstall Intuit's TurboTax at this time, so there's no way to get HP Connection Manager installed to determine for sure what SQLite-related DLLs it installs). Regards, Joe It's a bit of a kludge, but ...you can go ahead and reinstall HP's Connection Manager. When you want to run TurboTax ...just *temporarily* rename the conflicting parent directory (C:\Program Files\HP Connection Manager to C:\Program Files\HP Connection Manager_ ) and reboot your system. It will be unable to find the directory to load the conflicting files (or run HP Connection Manager). Then, run TurboTax to your heart's content and when finished ...rename the parent directory *back* (remove the underscore at the end of the directory name) and reboot to return HP Connection Manager to a "working" state. Cheers -- -- -- --ô¿ô-- K e V i N Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Joe Mistachkin To: 'General Discussion of SQLite Database' Date: Thu Jan 19 2012 10:06:09 GMT-0600 (Central Standard Time) Another thing to keep in mind is that the System.Data.SQLite project compiles the native code for SQLite into files named "SQLite.Interop.dll" and "System.Data.SQLite.dll" (mixed-mode assembly), depending on the build configuration. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Incompatible versions of SQLite on same system
Joe, Good to know! I had been looking just for . I don't have access to the machine right now, but I do have a clone of its system drive, and a search for turned up: System.Data.SQLite.Linq.DLL (more than one copy) System.Data.SQLite.DLL (more than one copy) System.Data.SQLite64.DLL (probably because it's 64-bit W7) At the time the clone was made, HP Connection Manager wasn't on it, but HP Power Assistant was, and the latter's directory in Program Files contains both and , so there's a good chance that HP Connection Manager will have those, too (I am not willing to uninstall Intuit's TurboTax at this time, so there's no way to get HP Connection Manager installed to determine for sure what SQLite-related DLLs it installs). Regards, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Joe Mistachkin To: 'General Discussion of SQLite Database' Date: Thu Jan 19 2012 10:06:09 GMT-0600 (Central Standard Time) Another thing to keep in mind is that the System.Data.SQLite project compiles the native code for SQLite into files named "SQLite.Interop.dll" and "System.Data.SQLite.dll" (mixed-mode assembly), depending on the build configuration. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Incompatible versions of SQLite on same system
Excellent point! I guess there's no solution that the end-user can deploy in this case. It's not even clear to me how the HP and/or Intuit programmers can solve the problem, since I replaced the HP Connection Manager with the latest one and TurboTax doesn't even have a anywhere in its directory structure and there isn't a in any system directory and when the fails, there isn't even a that's been loaded in memory. Regards, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Jean-Christophe Deschamps To: General Discussion of SQLite Database Date: Mon Jan 16 2012 18:18:06 GMT-0600 (Central Standard Time) At 01:08 17/01/2012, you wrote: ´¯¯¯ Richard, Simon, and you are seeing eye-to-eye on this. Earlier in the thread (since trimmed, of course), it was stated that SQLite was designed to be tiny so that each app could include the entire system without draining resources significantly (this would solve the problem of apps stepping on each other with different versions of ). So if that's the case, why not kill the distribution of and force the developers to do it the right way? Regards, Joe `--- That would preclude use of SQLite in situation where no linking is possible, like many scripting languages, etc. That it is allright for your current use cases doesn't imply it's convenient or even possible for others. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Incompatible versions of SQLite on same system
> The search path stuff is a mess under Microsoft. Yes, it sure is. The link you sent has some interesting stuff. In particular, this point is key: Before the system searches for a DLL, it checks the following: (1) If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL. (2) If the DLL is on the list of known DLLs for the version of Windows on which the application is running, the system uses its copy of the known DLL (and the known DLL's dependent DLLs, if any). The system does not search for the DLL. For a list of known DLLs on the current system, see the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs. Re (1), I ran a report to view loaded DLLs and no version of SQLite is there. Re (2), I checked the registry entry shown and no version of SQLite is in the KnownDLLs key. With (1) and (2) out of the way, the search order is clear: regardless of the SafeDllSearchMode setting, it will always search the directory from which the application loaded first. Hence, copying the latest into the Connection Manager app directory should have worked, but it did not (see below). > you may be able to copy the latest sqlite3.dll into the one application directory and replace the old one. That's what I did to the one in the HP Connection Manager directory. Didn't fix the problem. There is no anywhere in the TurboTax directory structure, so nothing to replace. Yet everyone reporting the problem on the HP forum says the problem started when they installed TT (CM is typically pre-installed on HP machines and works fine until TT is installed). > To the best of my knowledge it's upwards compatible. Yes, Richard stated that much earlier in the thread ("SQLite is always backwards compatible."), but it has long since been trimmed out, as frequent and heavy trimming seems to be the MO in this group. Speaking of that, I also documented ALL of the files earlier in the thread. In addition to CM, they are: c:\Program Files (x86)\Calibre2\DLLs\sqlite3.dll c:\Program Files (x86)\Common Files\Apple\Apple Application Support\SQLite3.dll c:\Program Files (x86)\Nuance\PaperPort\sqlite3.dll Calibre and PaperPort are working fine (so is TT). The only piece of Apple software on the machine is QuickTime, and it is working fine. None of them copied the SQLite DLL into a system folder and none of them placed it in the list of known DLLs. > Anybody who uses an SQLite DLL should be hung up by their boots. Richard, Simon, and you are seeing eye-to-eye on this. Earlier in the thread (since trimmed, of course), it was stated that SQLite was designed to be tiny so that each app could include the entire system without draining resources significantly (this would solve the problem of apps stepping on each other with different versions of ). So if that's the case, why not kill the distribution of and force the developers to do it the right way? Regards, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Black, Michael (IS) To: General Discussion of SQLite Database Date: Monday, January 16, 2012 14:40:23 You don't need to "register" the SQLite DLL. That's for ActiveX and COM DLLs. Not ones that just export functions. The search path stuff is a mess under Microsoft. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx#standard_search_order_for_desktop_applications You may be able to get away with getting rid of ALL sqlite3.dll's and just putting the latest version in %SystemRoot%\system32 -- or you may be able to copy the latest sqlite3.dll into the one application directory and replace the old one. To the best of my knowledge it's upwards compatible. Anybody who uses an SQLite DLL should be hung up by their boots. Michael D. Black Senior Scientist Advanced Analytics Directorate Advanced GEOINT Solutions Operating Unit Northrop Grumman Information Systems ___ ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Incompatible versions of SQLite on same system
Ah, I see that embedded images don't make it in this group, so the screen shot referred to in my previous message is attached. Regards, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Joe Winograd To: General Discussion of SQLite Database Date: Monday, January 16, 2012 13:40:58 Thanks for the response, Michael. This is a 64-bit W7 machine. The two supposedly conflicting programs are: c:\Program Files (x86)\TurboTax\Home & Business 2010\32bit\TurboTax.exe c:\Program Files (x86)\Hewlett-Packard\HP Connection Manager\HPConnectionManager.exe TurboTax does not have a copy of anywhere in its directory structure. Connection Manager does. I had reported earlier that CM didn't, but that was my mistake, probably because I uninstalled it before doing the search for . I just reinstalled CM and got the same dialog as previously reported – and subsequently trimmed. :) I downloaded the latest from the link that Richard provided and replaced the copy in Connection Manager>. Running CM fails in the same way as previously reported and running (which is in the same directory as the CM executable and the new ) also fails in the same way as previously reported. I did not copy the new into (x86)\TurboTax\Home & Business 2010\32bit\>, as there is no version to replace. Does it still make sense to copy it into this directory, where resides? A couple of other possibly worthy tidbits: (1) I ran a DLL report before and after attempting the CM install. It did not show any registered. (2) I attempted to register manually (via RegSvr32) the new . It gives this error dialog: SQLite3-DLL-regsvr32-error CM still failed in the same way. Further ideas? Thanks, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Black, Michael (IS) To: General Discussion of SQLite Database Date: Sunday, January 15, 2012 13:56:33 My point still standsyou can test the application compatibility by copying the DLL into the app directory and changing the search order as I recommended. Did you try that? The applications really need to compile sqlite in their app. That's the good fix here as has been pointed out (and something I always do). But good luck with that one. Michael D. Black Senior Scientist Advanced Analytics Directorate Advanced GEOINT Solutions Operating Unit Northrop Grumman Information Systems From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Joe Winograd [j...@winograd.us] Sent: Sunday, January 15, 2012 1:52 PM To: General Discussion of SQLite Database Subject: EXT :Re: [sqlite] Incompatible versions of SQLite on same system I don't really mind top or bottom post. I don't either, but it really should be one or the other; otherwise, you're jumping up and down to follow a thread. But that's because of the next point, where we disagree completely. > But the important thing is to trim anything you've quoted to just the useful bits. We don't need to see every single post to the thread every time someone adds a new post. I strongly disagree with this. In personal (one-on-one) correspondence, it makes sense, but not in email-based groups/forums, where members come and go at various points in time. A member should be able to jump into a thread and easily review the whole issue in one email. Having to go back and look at every trimmed message to piece together the entire thread is painful and, frankly, won't usually be done. This is also why top posting is better. The combination of the two (NOT trimming and top posting) means that a new entrant to the discussion can review the entire thread in one email (admittedly, having to page-up) while someone who has been participating in the discussion for a while can simply look at the top-posted most recent response(s). I think we actually have an example of the trimming problem in this thread. I may be wrong, and Michael Black may jump in to say I'm wrong, but a key comment of mine had been trimmed, viz., the doesn't even appear in the application directory of the two conflicting apps. If Michael had seen that in a non-trimmed message, I'm guessing he would not have said, "Can't you just copy the DLL into the application directory?" Come to think of it, by the time it got to Michael, "TurboTax" and "HP Connection Manager" (the two conflicting programs) had been trimmed out of the message. I would argue that those are "useful bits" of this thread. I think there are times when trimming is appropriate, but in most cases, I think that threads should be left intact. Just my humble, of course. Cheers, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: S
Re: [sqlite] Incompatible versions of SQLite on same system
Thanks for the response, Michael. This is a 64-bit W7 machine. The two supposedly conflicting programs are: c:\Program Files (x86)\TurboTax\Home & Business 2010\32bit\TurboTax.exe c:\Program Files (x86)\Hewlett-Packard\HP Connection Manager\HPConnectionManager.exe TurboTax does not have a copy of anywhere in its directory structure. Connection Manager does. I had reported earlier that CM didn't, but that was my mistake, probably because I uninstalled it before doing the search for . I just reinstalled CM and got the same dialog as previously reported – and subsequently trimmed. :) I downloaded the latest from the link that Richard provided and replaced the copy in Connection Manager>. Running CM fails in the same way as previously reported and running (which is in the same directory as the CM executable and the new ) also fails in the same way as previously reported. I did not copy the new into (x86)\TurboTax\Home & Business 2010\32bit\>, as there is no version to replace. Does it still make sense to copy it into this directory, where resides? A couple of other possibly worthy tidbits: (1) I ran a DLL report before and after attempting the CM install. It did not show any registered. (2) I attempted to register manually (via RegSvr32) the new . It gives this error dialog: SQLite3-DLL-regsvr32-error CM still failed in the same way. Further ideas? Thanks, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Black, Michael (IS) To: General Discussion of SQLite Database Date: Sunday, January 15, 2012 13:56:33 My point still standsyou can test the application compatibility by copying the DLL into the app directory and changing the search order as I recommended. Did you try that? The applications really need to compile sqlite in their app. That's the good fix here as has been pointed out (and something I always do). But good luck with that one. Michael D. Black Senior Scientist Advanced Analytics Directorate Advanced GEOINT Solutions Operating Unit Northrop Grumman Information Systems From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Joe Winograd [j...@winograd.us] Sent: Sunday, January 15, 2012 1:52 PM To: General Discussion of SQLite Database Subject: EXT :Re: [sqlite] Incompatible versions of SQLite on same system I don't really mind top or bottom post. I don't either, but it really should be one or the other; otherwise, you're jumping up and down to follow a thread. But that's because of the next point, where we disagree completely. > But the important thing is to trim anything you've quoted to just the useful bits. We don't need to see every single post to the thread every time someone adds a new post. I strongly disagree with this. In personal (one-on-one) correspondence, it makes sense, but not in email-based groups/forums, where members come and go at various points in time. A member should be able to jump into a thread and easily review the whole issue in one email. Having to go back and look at every trimmed message to piece together the entire thread is painful and, frankly, won't usually be done. This is also why top posting is better. The combination of the two (NOT trimming and top posting) means that a new entrant to the discussion can review the entire thread in one email (admittedly, having to page-up) while someone who has been participating in the discussion for a while can simply look at the top-posted most recent response(s). I think we actually have an example of the trimming problem in this thread. I may be wrong, and Michael Black may jump in to say I'm wrong, but a key comment of mine had been trimmed, viz., the doesn't even appear in the application directory of the two conflicting apps. If Michael had seen that in a non-trimmed message, I'm guessing he would not have said, "Can't you just copy the DLL into the application directory?" Come to think of it, by the time it got to Michael, "TurboTax" and "HP Connection Manager" (the two conflicting programs) had been trimmed out of the message. I would argue that those are "useful bits" of this thread. I think there are times when trimming is appropriate, but in most cases, I think that threads should be left intact. Just my humble, of course. Cheers, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Simon Slavin To: General Discussion of SQLite Database Date: Thursday, January 12, 2012 19:54:56 On 13 Jan 2012, at 1:46am, Joe Winograd wrote: Thanks for the clarification. My pleasure. Triggers do generally work in the most useful way. Try coding it and see if it works for you. Btw, is bottom-posting the standard in this group? As you can tell, I&
Re: [sqlite] Incompatible versions of SQLite on same system
> I don't really mind top or bottom post. I don't either, but it really should be one or the other; otherwise, you're jumping up and down to follow a thread. But that's because of the next point, where we disagree completely. > But the important thing is to trim anything you've quoted to just the useful bits. We don't need to see every single post to the thread every time someone adds a new post. I strongly disagree with this. In personal (one-on-one) correspondence, it makes sense, but not in email-based groups/forums, where members come and go at various points in time. A member should be able to jump into a thread and easily review the whole issue in one email. Having to go back and look at every trimmed message to piece together the entire thread is painful and, frankly, won't usually be done. This is also why top posting is better. The combination of the two (NOT trimming and top posting) means that a new entrant to the discussion can review the entire thread in one email (admittedly, having to page-up) while someone who has been participating in the discussion for a while can simply look at the top-posted most recent response(s). I think we actually have an example of the trimming problem in this thread. I may be wrong, and Michael Black may jump in to say I'm wrong, but a key comment of mine had been trimmed, viz., the doesn't even appear in the application directory of the two conflicting apps. If Michael had seen that in a non-trimmed message, I'm guessing he would not have said, "Can't you just copy the DLL into the application directory?" Come to think of it, by the time it got to Michael, "TurboTax" and "HP Connection Manager" (the two conflicting programs) had been trimmed out of the message. I would argue that those are "useful bits" of this thread. I think there are times when trimming is appropriate, but in most cases, I think that threads should be left intact. Just my humble, of course. Cheers, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Simon Slavin To: General Discussion of SQLite Database Date: Thursday, January 12, 2012 19:54:56 On 13 Jan 2012, at 1:46am, Joe Winograd wrote: Thanks for the clarification. My pleasure. Triggers do generally work in the most useful way. Try coding it and see if it works for you. Btw, is bottom-posting the standard in this group? As you can tell, I'm rather fond of top-posting. Yes, I've ready many of the arguments why bottom-posting is better – I simply don't buy it. But I'll be happy to comply with group standards. Bottom posting is the proper way to do it. I don't really mind top or bottom post. But the important thing is to trim anything you've quoted to just the useful bits. We don't need to see every single post to the thread every time someone adds a new post. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Incompatible versions of SQLite on same system
Simon, Thanks for the clarification. Btw, is bottom-posting the standard in this group? As you can tell, I'm rather fond of top-posting. Yes, I've ready many of the arguments why bottom-posting is better – I simply don't buy it. But I'll be happy to comply with group standards. Regards, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Simon Slavin To: General Discussion of SQLite Database Date: Thursday, January 12, 2012 03:59:02 On 12 Jan 2012, at 6:30am, Joe Winograd wrote: Thanks to both of you for your responses. I'm back to wondering how SQLite can be effective in the PC world with so many different programs using many different versions of SQLite. Since all versions are backward compatible, I was liking Richard's suggestion to get the latest-and-greatest DLL everywhere, but the DLLs for the two conflicting programs aren't even present. Joe, I assume your suggestion to "remove all System.Data.SQLite assemblies from the GAC and 'convert' them to be application-local" is directed at the software developers (like HP and Intuit), not at end-users (like me Just to be clear, so is Richard's real suggestion, which is the programmers should statically link to a SQLite library, or to include SQLite source code in their applications and not use a library at all. SQLite is (deliberately designed to be) tiny. Including it all in every application which used it wouldn't use much disk space and would mean problems like the one you reported would never happen: you could have ten apps all expecting different versions of SQLite, and they could all run at the same time with no installation or path problems. Unfortunately, as you noted, this is a decision which can be made only by programmers, not users like you. Oh, and in case you didn't know, Doctor Richard Hipp is SQLite's creator. His advice about it is pretty good. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Incompatible versions of SQLite on same system
Kevin and Joe, Thanks to both of you for your responses. I'm back to wondering how SQLite can be effective in the PC world with so many different programs using many different versions of SQLite. Since all versions are backward compatible, I was liking Richard's suggestion to get the latest-and-greatest DLL everywhere, but the DLLs for the two conflicting programs aren't even present. Joe, I assume your suggestion to "remove all System.Data.SQLite assemblies from the GAC and 'convert' them to be application-local" is directed at the software developers (like HP and Intuit), not at end-users (like me - I don't have a clue what the GAC is, nor should I have to in order to run TurboTax). Regards, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Joe Mistachkin To: 'General Discussion of SQLite Database' Date: Wednesday, January 11, 2012 19:06:46 Kevin Benson wrote: Since the System.Data.SQLite.dll is a mixed assembly (i.e. contains both managed& native code) in differing versions for x86 versus x64 , I wonder if HP meant TurboTax was using, for example, an x86 flavor of that DLL that conflicts with their (HP) program's use of an x64 flavor? Also, perhaps their application is binding to the exact version (which is typical)? One possible solution to this issue is to remove all System.Data.SQLite assemblies from the GAC and "convert" them to be application-local (i.e. they would only reside in the same directory as the application itself); however, this can be difficult, depending on how the application was written. -- Joe Mistachkin ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Incompatible versions of SQLite on same system
Well, this seems really strange - neither Connection Manager nor TurboTax has a ! Here are all of the ones on the system: c:\Program Files (x86)\Calibre2\DLLs\sqlite3.dll c:\Program Files (x86)\Common Files\Apple\Apple Application Support\SQLite3.dll c:\Program Files (x86)\Nuance\PaperPort\sqlite3.dll Any other thoughts? Thanks, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Joe Winograd To: General Discussion of SQLite Database Date: Wednesday, January 11, 2012 12:10:43 Richard, Thanks for the prompt reply - much appreciated! The machine with the issue is not onsite right now, but I expect to have it back in 4-5 hours. I will try your suggestion then and will post the results to the group. I have already complained to HP (both on the phone and in writing) and will file a report with Intuit later today. Thanks again, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Richard Hipp To: General Discussion of SQLite Database Date: Wednesday, January 11, 2012 11:56:19 On Wed, Jan 11, 2012 at 12:39 PM, Joe Winograd wrote: Hi Folks, First time poster here, so be gentle. I have an HP EliteBook 8460w running 64-bit W7. HP provides an app called the Connection Manager that allows you to control the status of the wired, wireless, and Bluetooth connections (it uses SQLite). CM was working fine until I installed TurboTax 2010, after which CM stopped working. When I uninstalled and reinstalled it, I received the following dialog box with the title: Cannot load assembly: System.Data.SQLite, Version=1.0.61.0, Culture =neutral, PublicKeyToken =db937bc2d44ff139 The application will now exit. According to HP tech supp, this is because TurboTax is loading an older version of the SQLite files and there is no way to fix the problem, i.e., you may use either use TT or CM, but not both! I'm hoping the experts in this forum have a solution to this problem, or at least a better work-around than uninstalling one and reinstalling the other each time I need one of the programs. This, of course, raises the general question of how SQLite programs/users deal with this issue. There are many programs that use SQLite - are all of them subject to this incompatibility issue? I find that hard to believe, as SQLite would not be a viable product if this were the case. Thanks much for your thoughts. Regards, Joe All: What was it I was saying just the other day about statically linking??? Joe: SQLite is always backwards compatible. But new features tend to appear in new releases. I suspect what is happening here is that HP Connection Manager is using newer features of SQLite that did not exist in the older version of SQLite that TurboTax is loading. I fuss and fuss that applications should statically link their preferred version of SQLite so that this kind of thing won't happen, but nobody pays me much mind. Please complain to both HP and Intuit about this as they might listen to you more than they listen to me. Meanwhile, I suggest you locate the SQLite3.dll file (or files) on your machine and replace them all with the latest version of SQLite3.dll that you can download from http://www.sqlite.org/download.html and that will probably fix your troubles, unless TurboTax has taken extraordinary measure to prevent you from doing so. Please let us know how this goes. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Incompatible versions of SQLite on same system
Richard, Thanks for the prompt reply - much appreciated! The machine with the issue is not onsite right now, but I expect to have it back in 4-5 hours. I will try your suggestion then and will post the results to the group. I have already complained to HP (both on the phone and in writing) and will file a report with Intuit later today. Thanks again, Joe Original Message Subject: Re: [sqlite] Incompatible versions of SQLite on same system From: Richard Hipp To: General Discussion of SQLite Database Date: Wednesday, January 11, 2012 11:56:19 On Wed, Jan 11, 2012 at 12:39 PM, Joe Winograd wrote: Hi Folks, First time poster here, so be gentle. I have an HP EliteBook 8460w running 64-bit W7. HP provides an app called the Connection Manager that allows you to control the status of the wired, wireless, and Bluetooth connections (it uses SQLite). CM was working fine until I installed TurboTax 2010, after which CM stopped working. When I uninstalled and reinstalled it, I received the following dialog box with the title: Cannot load assembly: System.Data.SQLite, Version=1.0.61.0, Culture =neutral, PublicKeyToken =db937bc2d44ff139 The application will now exit. According to HP tech supp, this is because TurboTax is loading an older version of the SQLite files and there is no way to fix the problem, i.e., you may use either use TT or CM, but not both! I'm hoping the experts in this forum have a solution to this problem, or at least a better work-around than uninstalling one and reinstalling the other each time I need one of the programs. This, of course, raises the general question of how SQLite programs/users deal with this issue. There are many programs that use SQLite - are all of them subject to this incompatibility issue? I find that hard to believe, as SQLite would not be a viable product if this were the case. Thanks much for your thoughts. Regards, Joe All: What was it I was saying just the other day about statically linking??? Joe: SQLite is always backwards compatible. But new features tend to appear in new releases. I suspect what is happening here is that HP Connection Manager is using newer features of SQLite that did not exist in the older version of SQLite that TurboTax is loading. I fuss and fuss that applications should statically link their preferred version of SQLite so that this kind of thing won't happen, but nobody pays me much mind. Please complain to both HP and Intuit about this as they might listen to you more than they listen to me. Meanwhile, I suggest you locate the SQLite3.dll file (or files) on your machine and replace them all with the latest version of SQLite3.dll that you can download from http://www.sqlite.org/download.html and that will probably fix your troubles, unless TurboTax has taken extraordinary measure to prevent you from doing so. Please let us know how this goes. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Incompatible versions of SQLite on same system
Hi Folks, First time poster here, so be gentle. I have an HP EliteBook 8460w running 64-bit W7. HP provides an app called the Connection Manager that allows you to control the status of the wired, wireless, and Bluetooth connections (it uses SQLite). CM was working fine until I installed TurboTax 2010, after which CM stopped working. When I uninstalled and reinstalled it, I received the following dialog box with the title : Cannot load assembly: System.Data.SQLite, Version=1.0.61.0, Culture =neutral, PublicKeyToken =db937bc2d44ff139 The application will now exit. According to HP tech supp, this is because TurboTax is loading an older version of the SQLite files and there is no way to fix the problem, i.e., you may use either use TT or CM, but not both! I'm hoping the experts in this forum have a solution to this problem, or at least a better work-around than uninstalling one and reinstalling the other each time I need one of the programs. This, of course, raises the general question of how SQLite programs/users deal with this issue. There are many programs that use SQLite - are all of them subject to this incompatibility issue? I find that hard to believe, as SQLite would not be a viable product if this were the case. Thanks much for your thoughts. Regards, Joe ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users