DXKeeper upgrade, from 15.9.9 to 16.1.5


Dave K2XR
 

Old subject, new thread.

Might be able to shed some light on the issue.   Here is my story.


When MODE was first extended from 8 to 12 chars, a few friends I
'support'  had the failure during the expansion process.

In each case I received, I discovered (using Access 2007 ) that all
processes were completed, but the temporaryfield4 was still in
existence. So when DXkeeper started up, it complained of too many fields
and exited gracefully.    Deleting the field restored functionality and
all was well under version 16.1.x

Until today...

Buddy sent his log, and I expected to find the same issue, but not so.  
Log contains approx 70k q's.

DXK error message upon conversion attempt is the same as reported in
previous instances of this thread:

Examining the errorlog as suggested  yielded this:

2021-06-19 12:33:46     > DXKeeper version 16.1.5
2021-06-19 12:33:46     > App.Path          : C:\DXLab\DXKeeper
2021-06-19 12:33:46     > App.exe           : DXKeeper
2021-06-19 12:33:46     > Module            : C:\DXLab\DXKeeper\DXKeeper.exe
2021-06-19 12:33:46     > Operating System  : Windows 10 Enterprise
(64-bit) build 19041
2021-06-19 12:33:46     > Locale ID         : 1033 (0x409)
2021-06-19 12:33:46     > ANSI CodePage     : 1252
2021-06-19 12:33:46     > OEM CodePage      : 437
2021-06-19 12:33:46     > Country           : United States
2021-06-19 12:33:46     > Language          : English
2021-06-19 12:33:46     > DecimalSeparator  : .
2021-06-19 12:33:46     > ThousandSeparator : ,
2021-06-19 12:33:46     > DXLab Apps        :
2021-06-19 12:35:31     > Monitors          : 3
2021-06-19 12:35:31     > Monitor 1
2021-06-19 12:35:31     >    width          : 1536
2021-06-19 12:35:31     >    height         : 864
2021-06-19 12:35:31     >    dimensions     : (0, 0)-(1536, 864)
2021-06-19 12:35:31     > Monitor 2
2021-06-19 12:35:31     >    width          : 1280
2021-06-19 12:35:31     >    height         : 720
2021-06-19 12:35:31     >    dimensions     : (1536, 5)-(2816, 725)
2021-06-19 12:35:31     > Monitor 3
2021-06-19 12:35:31     >    width          : 1280
2021-06-19 12:35:31     >    height         : 720
2021-06-19 12:35:31     >    dimensions     : (3072, 9)-(4352, 729)
2021-06-19 12:35:31.831 > program error 3035 in module
DXLogModule.UpdateFields, theState = 105, UpdateFields = 4,
SaveUpdateFields = : System resource exceeded.
2021-06-19 12:38:05.241 > Common.Terminate: DXKeeper shutdown


So I key in on the system resource exceeded clue.

Move to the machine with the most RAM in the house  (16gb)  and same
error message is returned.

Browsed the archives for the latest  and read the thread generated by
message #  201752  same subject as above.

Tell friend to send the log to you...      but before he does, I decide
to  try another method...

Back to Access, open the log. Go to the QSO table,enter design mode,
find the mode field ...  change length from 8 to 12

Access wants me to save the changes and reopen the mdb.   So I try...

Access throws an error similar to the errorlog report, but with a few
suggestions as to why.

Either :   You have changed the field to no duplicates, and there
already were duplicates  ( discarded   since hey... it's mode ;) )

or :  You have an insufficient number or locks available....  if you
wish to try and fix this, look at this registry entry  ( the access
registry )  and change the value to a higher number ... with appropriate
warnings on fooling with the registry.

So I look at the entry on my Access machine .  The value name is
maxlocksperfile   and it was set to 9500 in the machine I was doing this on.


Not wishing to go any further, I zipped his log, sent it back to him,
and told him to send it to you per suggestions seen fairly frequently.

He mailed it at the same time I posted this.

   XR Dave


Dave AA6YQ
 

Old subject, new thread.

Might be able to shed some light on the issue. Here is my story.


When MODE was first extended from 8 to 12 chars, a few friends I 'support' had the failure during the expansion process.

In each case I received, I discovered (using Access 2007 ) that all processes were completed, but the temporaryfield4 was still in existence. So when DXkeeper started up, it complained of too many fields and exited gracefully. Deleting the field restored functionality and all was well under version 16.1.x

Until today...

Buddy sent his log, and I expected to find the same issue, but not so. Log contains approx 70k q's.

DXK error message upon conversion attempt is the same as reported in previous instances of this thread:

Examining the errorlog as suggested yielded this:

2021-06-19 12:33:46 > DXKeeper version 16.1.5
2021-06-19 12:33:46 > App.Path : C:\DXLab\DXKeeper
2021-06-19 12:33:46 > App.exe : DXKeeper
2021-06-19 12:33:46 > Module : C:\DXLab\DXKeeper\DXKeeper.exe
2021-06-19 12:33:46 > Operating System : Windows 10 Enterprise
(64-bit) build 19041
2021-06-19 12:33:46 > Locale ID : 1033 (0x409)
2021-06-19 12:33:46 > ANSI CodePage : 1252
2021-06-19 12:33:46 > OEM CodePage : 437
2021-06-19 12:33:46 > Country : United States
2021-06-19 12:33:46 > Language : English
2021-06-19 12:33:46 > DecimalSeparator : .
2021-06-19 12:33:46 > ThousandSeparator : ,
2021-06-19 12:33:46 > DXLab Apps :
2021-06-19 12:35:31 > Monitors : 3
2021-06-19 12:35:31 > Monitor 1
2021-06-19 12:35:31 > width : 1536
2021-06-19 12:35:31 > height : 864
2021-06-19 12:35:31 > dimensions : (0, 0)-(1536, 864)
2021-06-19 12:35:31 > Monitor 2
2021-06-19 12:35:31 > width : 1280
2021-06-19 12:35:31 > height : 720
2021-06-19 12:35:31 > dimensions : (1536, 5)-(2816, 725)
2021-06-19 12:35:31 > Monitor 3
2021-06-19 12:35:31 > width : 1280
2021-06-19 12:35:31 > height : 720
2021-06-19 12:35:31 > dimensions : (3072, 9)-(4352, 729)
2021-06-19 12:35:31.831 > program error 3035 in module DXLogModule.UpdateFields, theState = 105, UpdateFields = 4, SaveUpdateFields = : System resource exceeded.
2021-06-19 12:38:05.241 > Common.Terminate: DXKeeper shutdown


So I key in on the system resource exceeded clue.

Move to the machine with the most RAM in the house (16gb) and same error message is returned.

+ Microsoft uses a much broader definition of "System resource" than "available RAM".


Browsed the archives for the latest and read the thread generated by message # 201752 same subject as above.

Tell friend to send the log to you... but before he does, I decide to try another method...

Back to Access, open the log. Go to the QSO table,enter design mode, find the mode field ... change length from 8 to 12

Access wants me to save the changes and reopen the mdb. So I try...

Access throws an error similar to the errorlog report, but with a few suggestions as to why.

Either : You have changed the field to no duplicates, and there already were duplicates ( discarded since hey... it's mode ;) )

or : You have an insufficient number or locks available.... if you wish to try and fix this, look at this registry entry ( the access registry ) and change the value to a higher number ... with appropriate warnings on fooling with the registry.

So I look at the entry on my Access machine . The value name is maxlocksperfile and it was set to 9500 in the machine I was doing this on.


Not wishing to go any further, I zipped his log, sent it back to him, and told him to send it to you per suggestions seen fairly frequently.

He mailed it at the same time I posted this.

+ The only correlation I've been able to establish is that attempting to expand a log's Mode file from 8 to 12 characters is more likely to fail on a computer running Windows 10. DXKeeper running on Windows 7 has successfully upgraded every log sent to me, including one with more than 300K QSOs.

73,

Dave, AA6YQ


KA9JAC
 

Dave,

Is it possible that compacting the file before the upgrade might help?

73
Bob, KA9JAC

PS no issues here, Everything works as it should :-)

On 6/19/2021 1:42 PM, Dave AA6YQ wrote:
Old subject, new thread.

Might be able to shed some light on the issue. Here is my story.


When MODE was first extended from 8 to 12 chars, a few friends I 'support' had the failure during the expansion process.

In each case I received, I discovered (using Access 2007 ) that all processes were completed, but the temporaryfield4 was still in existence. So when DXkeeper started up, it complained of too many fields and exited gracefully. Deleting the field restored functionality and all was well under version 16.1.x

Until today...

Buddy sent his log, and I expected to find the same issue, but not so. Log contains approx 70k q's.

DXK error message upon conversion attempt is the same as reported in previous instances of this thread:

Examining the errorlog as suggested yielded this:

2021-06-19 12:33:46 > DXKeeper version 16.1.5
2021-06-19 12:33:46 > App.Path : C:\DXLab\DXKeeper
2021-06-19 12:33:46 > App.exe : DXKeeper
2021-06-19 12:33:46 > Module : C:\DXLab\DXKeeper\DXKeeper.exe
2021-06-19 12:33:46 > Operating System : Windows 10 Enterprise
(64-bit) build 19041
2021-06-19 12:33:46 > Locale ID : 1033 (0x409)
2021-06-19 12:33:46 > ANSI CodePage : 1252
2021-06-19 12:33:46 > OEM CodePage : 437
2021-06-19 12:33:46 > Country : United States
2021-06-19 12:33:46 > Language : English
2021-06-19 12:33:46 > DecimalSeparator : .
2021-06-19 12:33:46 > ThousandSeparator : ,
2021-06-19 12:33:46 > DXLab Apps :
2021-06-19 12:35:31 > Monitors : 3
2021-06-19 12:35:31 > Monitor 1
2021-06-19 12:35:31 > width : 1536
2021-06-19 12:35:31 > height : 864
2021-06-19 12:35:31 > dimensions : (0, 0)-(1536, 864)
2021-06-19 12:35:31 > Monitor 2
2021-06-19 12:35:31 > width : 1280
2021-06-19 12:35:31 > height : 720
2021-06-19 12:35:31 > dimensions : (1536, 5)-(2816, 725)
2021-06-19 12:35:31 > Monitor 3
2021-06-19 12:35:31 > width : 1280
2021-06-19 12:35:31 > height : 720
2021-06-19 12:35:31 > dimensions : (3072, 9)-(4352, 729)
2021-06-19 12:35:31.831 > program error 3035 in module DXLogModule.UpdateFields, theState = 105, UpdateFields = 4, SaveUpdateFields = : System resource exceeded.
2021-06-19 12:38:05.241 > Common.Terminate: DXKeeper shutdown


So I key in on the system resource exceeded clue.

Move to the machine with the most RAM in the house (16gb) and same error message is returned.

+ Microsoft uses a much broader definition of "System resource" than "available RAM".


Browsed the archives for the latest and read the thread generated by message # 201752 same subject as above.

Tell friend to send the log to you... but before he does, I decide to try another method...

Back to Access, open the log. Go to the QSO table,enter design mode, find the mode field ... change length from 8 to 12

Access wants me to save the changes and reopen the mdb. So I try...

Access throws an error similar to the errorlog report, but with a few suggestions as to why.

Either : You have changed the field to no duplicates, and there already were duplicates ( discarded since hey... it's mode ;) )

or : You have an insufficient number or locks available.... if you wish to try and fix this, look at this registry entry ( the access registry ) and change the value to a higher number ... with appropriate warnings on fooling with the registry.

So I look at the entry on my Access machine . The value name is maxlocksperfile and it was set to 9500 in the machine I was doing this on.


Not wishing to go any further, I zipped his log, sent it back to him, and told him to send it to you per suggestions seen fairly frequently.

He mailed it at the same time I posted this.

+ The only correlation I've been able to establish is that attempting to expand a log's Mode file from 8 to 12 characters is more likely to fail on a computer running Windows 10. DXKeeper running on Windows 7 has successfully upgraded every log sent to me, including one with more than 300K QSOs.

73,

Dave, AA6YQ




--
This email has been checked for viruses by AVG.
https://www.avg.com


Dave AA6YQ
 

Is it possible that compacting the file before the upgrade might help?

+ Experiments have not shown that compacting beforehand makes a difference.

73,

Dave, AA6YQ


Dave K2XR
 

Concur, same finding here.

On 6/19/2021 3:26:36 PM, Dave AA6YQ wrote:
Is it possible that compacting the file before the upgrade might help?

+ Experiments have not shown that compacting beforehand makes a difference.

73,
Dave, AA6YQ