in reply to Re^3: Opening a SQLite DB after accessing it w/ DBI module
in thread Opening a SQLite DB after accessing it w/ DBI module
A little exploration revealed that on Win|Active State 5.014, there is no sqlite.exe or sqlite3.exe in Perl's directories. Rather, C:\>dir sqlite*.* /s/a tells us:
Directory of C:\Perl\lib\auto\DBD 01/29/2012 07:38 PM <DIR> SQLite 0 File(s) 0 bytes Directory of C:\Perl\lib\auto\DBD\SQLite 10/07/2011 04:27 PM 0 SQLite.bs 10/07/2011 04:27 PM 487,542 SQLite.dll 10/07/2011 04:27 PM 804 SQLite.exp 10/07/2011 04:27 PM 2,170 SQLite.lib 4 File(s) 490,516 bytes Directory of C:\Perl\lib\auto\share\dist\DBD-SQLite 10/07/2011 04:27 PM 4,438,903 sqlite3.c 10/07/2011 04:27 PM 306,213 sqlite3.h 2 File(s) 4,745,116 bytes Directory of C:\Perl\lib\CPANPLUS\Internals\Source 01/29/2012 07:38 PM <DIR> SQLite 04/22/2011 02:42 PM 9,627 SQLite.pm 1 File(s) 9,627 bytes Directory of C:\Perl\lib\DBD 01/29/2012 07:38 PM <DIR> SQLite 05/30/2011 12:30 AM 67,126 SQLite.pm 1 File(s) 67,126 bytes
The list continues with instanges from other packages -- Adobe Reader 9, for instance, has a .dll (no version number in the filename) about half the size of that provided by DBI; LibreOffice has still another that runs to 400K.
Interestingly (to me anyway) is that yet another program -- a commercial package for syncing my fone with an old Palm PIM -- has two .dll's:
503,202 sqlite3_3_6_16.dll 559,244 sqlite3_3_7_5.dll
Tentative conclusion: providers, including AS, pick and chose which version of sqlite3 they utilize... and may rename to their own taste.
Afterthought speculation: Were my Linux box not still recouperating from a drive transplant and other surgery, I'd bet on finding a standalone version of "sqlite3.exe" there (as I do on another drive on the Win7 box) ... but by the name of "sqlite" -- perhaps others will check names and versions on RedHat, Debian, etc....
|
|---|