Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - leedell

Pages: [1]
1
I'd be curious to see what your wrote for this scenario.

> I ended up adding the keywords via C# and a SQL Server stored procedure - it's faster and works every time. In hindsight I should have taken this approach first off but I got lazy thinking TPCMD would do it for me. (Naughty programmer!!). The only time I call TPCmd in the whole exercise now is to do an UpdateAll() and then OpenDir() to update and re-select the folder so ThumbsPlus refreshes all the images.

2
Timimg!  I encountered some issues in a fresh database in ThumbsPlus 10 trying to use TPCMD and submitted a support request on June 27th.  I hadn't checked the forums.

You might find this excerpt of the submission of use to explain the seeming randomness of the behavior.  I determined that it's a buffer/string not being cleared between DDE requests to ThumbsPlus:

I've used TPCMD often under version 7, mostly ScanTree() and Keyword().  
Since I've been unable to get TP10 to accept a TP7 text export or to
convert a copy of a TP7 database to the new format, I decided to just
build all the thumbnails in TP10's new database, then use a
very...very...long .BAT file to assign keywords to the files.  
Unfortunately, TP10 doesn't properly respond to TPCMD requests for scans
or keywords.

When the error occurs for keywords, it just doesn't "appear" to do anything.

For scans, at least the Task List in Thumbs 10 shows me what's wrong.
The following occurs in SP1-Beta2 (Build 4007) and SP1 (Build 4011).

Commands:
tpcmd ScanTree("T:\Pix\January")
tpcmd ScanTree("T:\Pix\February")
tpcmd ScanTree("T:\Pix\March")
tpcmd ScanTree("T:\Pix\April")
tpcmd ScanTree("T:\Pix\May")
tpcmd ScanTree("T:\Pix\June")
tpcmd ScanTree("T:\Pix\July")
tpcmd ScanTree("T:\Pix\August")
tpcmd ScanTree("T:\Pix\September")
tpcmd ScanTree("T:\Pix\October")
tpcmd ScanTree("T:\Pix\November")
tpcmd ScanTree("T:\Pix\December")

Resulting Task list:
Scan Tree: T:\Pix\January
Scan Tree: T:\Pix\February
Scan Tree: T:\Pix\March)ry
Scan Tree: T:\Pix\April)ry
Scan Tree: T:\Pix\May)l)ry
Scan Tree: T:\Pix\June))ry
Scan Tree: T:\Pix\July))ry
Scan Tree: T:\Pix\August)y
Scan Tree: T:\Pix\September
Scan Tree: T:\Pix\October)r
Scan Tree: T:\Pix\November)
Scan Tree: T:\Pix\December)
--
Normally, with ThumbsPlus 7, I would do this with

for /F "tokens=*" %f in (%temp%\dirlist.txt) do tpcmd ScanTree("%f")&sleep 1

Due to the error in ThumbsPlus 10, I have to sort the lines in the
directory list by increasing length. For the moment, I'm working around
the buffer error with the following, which depends upon awk, sed and
sort from GnuWin32

cat %temp%\dirlist.txt | awk "{print length,$0}" | sort -n | sed -e
"s;^[0-9]* ;;" > %temp%\dirlist_sorted.txt & for /F "tokens=*" %f in
(%temp%\dirlist_sorted.txt) do tpcmd ScanTree("%f")&sleep 1

3
Speed comes with a price. When OS/2 went live, it used Microsoft's code for disk transactions, among other things, rather than the code that IBM had presented. The reason was that in testing, Microsoft's code was much, much faster. Later, they found out why: Microsoft had removed all parameter checking from the test code. So, as long as the calling program never supplied incorrect or impossible values....

To my point, though, using some of those options eliminates the safety nets in the client.
As stated at https://www.sqlite.org/pragma.html#pragma_journal_mode

PRAGMA schema.journal_mode;
PRAGMA schema.journal_mode = DELETE | TRUNCATE | PERSIST | MEMORY | WAL | OFF

This pragma queries or sets the journal mode for databases associated with the current database connection.

The first form of this pragma queries the current journaling mode for database. When database is omitted, the "main" database is queried.

The second form changes the journaling mode for "database" or for all attached databases if "database" is omitted. The new journal mode is returned. If the journal mode could not be changed, the original journal mode is returned.

The DELETE journaling mode is the normal behavior. In the DELETE mode, the rollback journal is deleted at the conclusion of each transaction. Indeed, the delete operation is the action that causes the transaction to commit. (See the document titled Atomic Commit In SQLite for additional detail.)

The TRUNCATE journaling mode commits transactions by truncating the rollback journal to zero-length instead of deleting it. On many systems, truncating a file is much faster than deleting the file since the containing directory does not need to be changed.

The PERSIST journaling mode prevents the rollback journal from being deleted at the end of each transaction. Instead, the header of the journal is overwritten with zeros. This will prevent other database connections from rolling the journal back. The PERSIST journaling mode is useful as an optimization on platforms where deleting or truncating a file is much more expensive than overwriting the first block of a file with zeros. See also: PRAGMA journal_size_limit and SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT.

The MEMORY journaling mode stores the rollback journal in volatile RAM. This saves disk I/O but at the expense of database safety and integrity. If the application using SQLite crashes in the middle of a transaction when the MEMORY journaling mode is set, then the database file will very likely go corrupt.

The WAL journaling mode uses a write-ahead log instead of a rollback journal to implement transactions. The WAL journaling mode is persistent; after being set it stays in effect across multiple database connections and after closing and reopening the database. A database in WAL journaling mode can only be accessed by SQLite version 3.7.0 (2010-07-21) or later.

The OFF journaling mode disables the rollback journal completely. No rollback journal is ever created and hence there is never a rollback journal to delete. The OFF journaling mode disables the atomic commit and rollback capabilities of SQLite. The ROLLBACK command no longer works; it behaves in an undefined way. Applications must avoid using the ROLLBACK command when the journal mode is OFF. If the application crashes in the middle of a transaction when the OFF journaling mode is set, then the database file will very likely go corrupt.

Note that the journal_mode for an in-memory database is either MEMORY or OFF and can not be changed to a different value. An attempt to change the journal_mode of an in-memory database to any setting other than MEMORY or OFF is ignored. Note also that the journal_mode cannot be changed while a transaction is active.

4
So, from what I've seen, the best approach to actually get going is:

Export Existing TP7 Client/Server DB to one or more text files
Create New TP8 Client/Server DB
Connect to TP8 Client/Server DB using TP8
Import Data from TP7 export file(s)

Given how long the failed database conversion took, I expect that this will probably be time consuming for my database AND will require multiple text files to keep them of reasonable size (under 2GB each would probably be sanest).

However, it presents me with an opportunity of sorts.
Currently, I'm running TP7 with an MS SQL Server 2000 back end running under MS Windows 2000 Server.  I've had to hold off on upgrading/replacing the server system simply because MS SQL 2K has compatibility issues under newer versions of WIndows and a lot of newer hardware (read that: hard drive controllers and motherboards) don't include drivers for Win 2K.

Switching to a different DB back end would allow me to upgrade to a newer system (with faster CPU, faster bus, faster and more RAM and faster and bigger HDs) running...say...Debian Linux and postgreSQL 9.

Does anyone see any caveats to this approach?

Pages: [1]