Incompatible versions of SQLite on same system

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Incompatible versions of SQLite on same system

Joe Winograd-2
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 <dbUpdate.exe>:

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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Incompatible versions of SQLite on same system

Richard Hipp-3
On Wed, Jan 11, 2012 at 12:39 PM, Joe Winograd <[hidden email]> 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 <dbUpdate.exe>:
>
> 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
> [hidden email]
> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users>
>



--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Incompatible versions of SQLite on same system

Joe Winograd-2
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 <[hidden email]>
To: General Discussion of SQLite Database <[hidden email]>
Date: Wednesday, January 11, 2012 11:56:19

> On Wed, Jan 11, 2012 at 12:39 PM, Joe Winograd<[hidden email]>  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<dbUpdate.exe>:
>>
>> 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: table names on the fly

inq1ltd

sqlite help,

Can someone tell me how to get the column names
contained in a table on the fly.  
 Col names are altered and added by a front end program
and I want to detect the column names while the DB is
in use.

I would appreciate the help.

jd
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: table names on the fly

Igor Tandetnik
On 1/11/2012 3:53 PM, inq1ltd wrote:
> Can someone tell me how to get the column names
> contained in a table on the fly.

Prepare a statement of the form "select * from mytable;" (no need to
actually run it), then use sqlite3_column_count and sqlite3_column_name[16].

Alternatively, execute PRAGMA table_info(mytable), and examine the
resultset.
--
Igor Tandetnik

_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: table names on the fly

Petite Abeille-2
In reply to this post by inq1ltd

On Jan 11, 2012, at 9:53 PM, inq1ltd wrote:

> Can someone tell me how to get the column names
> contained in a table on the fly.  

pragma table_info
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: table names on the fly

inq1ltd
On Wednesday, January 11, 2012 09:58:17 PM Petite
Abeille wrote:

> On Jan 11, 2012, at 9:53 PM, inq1ltd wrote:
> > Can someone tell me how to get the column names
> > contained in a table on the fly.
>
> pragma table_info
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlit
> e-users
That helps, thanks
jd
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Incompatible versions of SQLite on same system

Joe Winograd-2
In reply to this post by Joe Winograd-2
Well, this seems really strange - neither Connection Manager nor TurboTax
has a <SQLite3.dll>! 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 <[hidden email]>
To: General Discussion of SQLite Database <[hidden email]>
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 <[hidden email]>
> To: General Discussion of SQLite Database <[hidden email]>
> Date: Wednesday, January 11, 2012 11:56:19
>> On Wed, Jan 11, 2012 at 12:39 PM, Joe Winograd<[hidden email]>  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<dbUpdate.exe>:
>>>
>>> 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Incompatible versions of SQLite on same system

Kevin Benson
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?

On 1/11/12, Joe Winograd <[hidden email]> wrote:

> Well, this seems really strange - neither Connection Manager nor TurboTax
> has a <SQLite3.dll>! 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 <[hidden email]>
> To: General Discussion of SQLite Database <[hidden email]>
> 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 <[hidden email]>
>> To: General Discussion of SQLite Database <[hidden email]>
>> Date: Wednesday, January 11, 2012 11:56:19
>>> On Wed, Jan 11, 2012 at 12:39 PM, Joe Winograd<[hidden email]>  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<dbUpdate.exe>:
>>>>
>>>> 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
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>


--
--
   --
      --
         --ô¿ô--
        K e V i N
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Incompatible versions of SQLite on same system

Joe Mistachkin-3

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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Incompatible versions of SQLite on same system

Joe Winograd-2
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 <[hidden email]>
To: 'General Discussion of SQLite Database' <[hidden email]>
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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Incompatible versions of SQLite on same system

Simon Slavin-3

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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: table names on the fly

John Gillespie-2
In reply to this post by Igor Tandetnik
Alternatively in tcl :
dbcmd eval { create table mytable ( aaa integer,  bbbb text) }
dbcmd eval { insert into mytable (aaa,bbb) values (1, 'zzzz')  }

dbcmd eval  "select * from mytable"  loopvar  {
     # loopvar(*)  contains the column names,   loopvar(aaa) contains 1,
loopvar(bbb) contains "zzzz"
}

On 11 January 2012 20:57, Igor Tandetnik <[hidden email]> wrote:

> On 1/11/2012 3:53 PM, inq1ltd wrote:
>
>> Can someone tell me how to get the column names
>> contained in a table on the fly.
>>
>
>
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Incompatible versions of SQLite on same system

Black, Michael (IS)
In reply to this post by Simon Slavin-3
Can't you just copy the DLL into the application directory?

That just does what the app ought to do (if they don't already).



Then you might have to turn off safe DLL mode to find the correct DLL unless you remove the system one.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx#standard_search_order_for_desktop_applications





Michael D. Black

Senior Scientist

Advanced Analytics Directorate

Advanced GEOINT Solutions Operating Unit

Northrop Grumman Information Systems

________________________________
From: [hidden email] [[hidden email]] on behalf of Simon Slavin [[hidden email]]
Sent: Thursday, January 12, 2012 3:59 AM
To: General Discussion of SQLite Database
Subject: EXT :Re: [sqlite] Incompatible versions of SQLite on same system


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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Incompatible versions of SQLite on same system

Joe Winograd-2
In reply to this post by Simon Slavin-3
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 <[hidden email]>
To: General Discussion of SQLite Database <[hidden email]>
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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Incompatible versions of SQLite on same system

Richard Hipp-3
gmail seems to really prefer to top-post.  I mix and match because it
doesn't bother me either way.

On Thu, Jan 12, 2012 at 8:46 PM, Joe Winograd <[hidden email]> wrote:

> 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 <[hidden email]>
> To: General Discussion of SQLite Database <[hidden email]>
> 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
> [hidden email]
> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users>
>



--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Incompatible versions of SQLite on same system

Simon Slavin-3
In reply to this post by Joe Winograd-2

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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Incompatible versions of SQLite on same system

Joe Winograd-2
 > 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 <SQLite3.dll> 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 <[hidden email]>
To: General Discussion of SQLite Database <[hidden email]>
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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Incompatible versions of SQLite on same system

Black, Michael (IS)
My point still stands....you 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: [hidden email] [[hidden email]] on behalf of Joe Winograd [[hidden email]]
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 <SQLite3.dll> 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 <[hidden email]>
To: General Discussion of SQLite Database <[hidden email]>
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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Incompatible versions of SQLite on same system

Joe Winograd-2
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 <SQLite3.dll> 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 <SQLite3.dll>. I just reinstalled CM and got the same
<DBUpdate.exe> dialog as previously reported – and subsequently trimmed. :)

I downloaded the latest <SQLite3.dll> from the link that Richard provided
and replaced the copy in <c:\Program Files (x86)\Hewlett-Packard\HP
Connection Manager>. Running CM fails in the same way as previously reported
and running <DBUpdate.exe> (which is in the same directory as the CM
executable and the new <SQLite3.dll>) also fails in the same way as
previously reported.

I did not copy the new <SQLite3.dll> into <c:\Program Files
(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
<TurboTax.exe> 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 <SQLite3.dll>
registered. (2) I attempted to register manually (via RegSvr32) the new
<SQLite3.dll>. 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) <[hidden email]>
To: General Discussion of SQLite Database <[hidden email]>
Date: Sunday, January 15, 2012 13:56:33

> My point still stands....you 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: [hidden email] [[hidden email]] on behalf of Joe Winograd [[hidden email]]
> 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<SQLite3.dll>  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<[hidden email]>
> To: General Discussion of SQLite Database<[hidden email]>
> 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
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
12