I just migrated from version 8 to version 12.01.3519 During replciation I get this strange message: Scanning logs starting at offset 0001738574 I. 2012-03-07 12:55:33. Processing transaction logs from directory "c:\perform\database\" E. 2012-03-07 12:55:33. Unable to open database file "c:\perform\database\Port32.db" -- Could not find or load the physical store DLL. I. 2012-03-07 12:55:33. Deleted old log file "c:\perform\database\120304AB.LOG" Note: Port32.Db is not part of the replciation system at all. This is a version 8 database that is just sitting in this directory...There are no log files from the port32.db in the directory. The actual replciation on the version 12 database appears to be working fine. Any ideas? Thanks.. asked 07 Mar '12, 14:58 TPS Breck Carter |
DBRemote needs to build a list of offline transaction log files and then sort them out at startup. In order to do so, DBRemote opens every single file from the offline transaction log directory and reads the first page of the file to see if it is a transaction log file or not. Starting from SA 10.0.0, the log format has been changed. Therefore, DBRemote from 10.0.0 and up will need an extra DLL, named dboftsp.dll (Windows) / libdboftsp_r.so.1 (UNIX) to read database and transaction log files generated by SA 9.0.2 and earlier. This DLL should be included in the SA installation. Please check it you have this file on your installation. answered 14 Mar '12, 17:45 Yufei Guo I am good with the answers. I just assumed dbremote only processed .log files. I guess the posting of this error message is new to post version 8... My application has had this file sitting here for the last 16 years. My next release I will move this file to another location. Thanks TPS
(14 Mar '12, 21:59)
TPS
Replies hidden
As Yufei and me have (see my comment above) stated, the error is probably due to the lack of the dboftsp.dll in the v12 setup. With v8/v9 (and older versions, methinks), DBREMOTE will simply have opened the v8 .db file (as DBREMOTE v8 does recognize the file format), found out that it isn't a log file, and just didn't put it to the list of offline log files.
(15 Mar '12, 04:20)
Volker Barth
|
Hm, having more than one database (including logs) in the same directory is not best-practise, methinks - particularly when the directory seems to be used as offline-log directory for SQL Remote or MobiLink...
This is no answer but possibly a hint.
This just sits there out of simplification. The database is never started or connected to.... It is a template that gets copied to a different location under a entirely different name. Than that database is connected to.....
I am just wondering why dbremote would even try to open or look at it. This database template file has nothing to do with the replciation system.
It open every file to see if it is a log file that is required for replication... what, you would prefer it rely on the naming convention?
If that is a pre-V10 database file, make sure the "Version 9 or earlier physical store library" (dboftsp.dll) is contained in your v12 setup...that should enable v12 to open the DB...
Nevertheless, I would change that DB's location:)
It is not a log file. It is a version 8 db file.
I do not want dbremote to open this file at all. It is not part of the messaging system. It is just sitting in the same location as the version 12 database that is part of the replcaition system....
In my next release I will move out this file from this location.
It just appeared strange to me that dbremote would even bother to look at this .db file
I agree that it should not issue such a confusing error message.
I DO NOT AGREE that it should not open the file. On the contrary, it SHOULD open the file because there is NO REQUIREMENT for any log file to have any particular file name, and dbremote HAS NO IDEA whether a particular file is a log file without opening it and looking inside it.
The only way you can tell dbremote that "it is not part of the messaging system" is by not storing it in that folder.
But yeah, it's a stupid error message...