Date   

Re: QSO looging to latest HRD v780

f1vev@...
 

Hi Alex  and I thought I was the only one  having this ? 
Chris  you are right that in the first  session trace I had the wrong logbook selected, Like Alex I rebuild all including logs , unlike alex mine never connected after rebuild  etc and this time entered the right  dabase name and  it connected so all is fine except for that final transfer  into HRD .

I now update HRD via a seperate  ADI import
CHeers Jacques 
--
Ic 7300 -  Win 10 Pro  - WJSTX 1.7 - JTalert 2.10.1 -  HRD 6.4.647 - Maria dB


Re: QSO looging to latest HRD v780

Chris VK2BYI
 
Edited

Thanks for your feedback Alex.

These sort of reports seem to be most often with MariaDB.  But my experience with MariaDB is no different than that with MySQL, which is they work.  I run SQL Server 2014 day-to-day, but that is because I worked with that for than 20 years before retiring.  But I do run several different tests on the various platforms before each release without problem.  That is why this is so frustrating.

As far as 32-bit/64-bit is concerned, I wouldn't have thought so.  HRD, WSJT-X, JTAlertX and QSO Relay are all 32-bit applications.  I have everything installed on my 64-bit development system, including 64-bit versions of SQL Server, MySQL and MariaDB.  I have no issues at all in connecting and testing against all of these database platforms,  apart from the occasional need to have an empty Access database open at the same time as a non-Access database.

Jacques' problem, according the session trace he sent, seems to be something to do with the actual connection - an error is generated: Unknown database 'f1vev'.  Usually the non-Access database issue where everything seems to work - except nothing gets written to the back-end database, doesn't generate any exceptions or error messages in the session trace files from memory.  Its like individual socks in my washing machine - the contacts just disappear without a sound or any trace!

73 Chris
VK2BYI


Re: QSO looging to latest HRD v780

Alex, W3ALX
 

I have been experiencing the same problem, and I've checked all the things mentioned before and see same results in trace log. Earlier today I uninstalled HRD and removed its data folder and re-installed. I left the new access database alone and configure HRD for the Maria database. I double checked all the settings in JTAlert and QSORelay, then gave it a test. everything worked great. I made several contacts and they all logged successfully. I closed HRD, JTAlert and WSJT-X; then re-opened everything - FAILED. With the reports of others not having the problem using the same versions of HRD, HJAlert and QSORelay, I'm wondering if HRD is having issues with newer version(s) of MariaDB or MySQL ODBC driver. I don't think I've seen very many (if any) reports on the versions in play for those two pieces of the puzzle. Also, could 64-bit versus 32-bit of MariaDB potentially an issue for QSORelay? 

73 to all --Alex
Yaesu FT-991A, Win 10 Pro, HRD 6.4.0.787, JTAlert 2.10.1, MariaDB x64 10.2.8.0, MySQL ODBC 5.3.9, QSORelay 1.7.6472.36182, WSJT-X 1.8.0-rc2


Re: QSO looging to latest HRD v780

f1vev@...
 

Thanks Chriss all check out ok but no logging  plus now getting pop up cannot relayached contacts.   I will leave things for the moment  getting ready for RTTY contest.

wil see later with a fesh mind  many hanks for all your  help and to Antony as well

73s Jacques --
Ic 7300 -  Win 10 Pro  - WJSTX 1.8 rc2 - JTalert 2.10.1-  HRD 6.4.787 - Maria dB QSO Relay  1.6


Re: QSO looging to latest HRD v780

Chris VK2BYI
 

Hi Jacques,

I did check your settings.config file, and the MySQL <ConnectionString></ConnectionString> setting looks fine to me.  I don't think your problem is being caused by anything incorrect in the settings.  But let's double check:

<?xml version="1.0"?>
<AppSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <ReceiveIpAddress>127.0.0.1</ReceiveIpAddress>   <--- correct
  <ReceiveUdpPort>2333</ReceiveUdpPort>                <--- correct
  <HrdIpAddress>127.0.0.1</HrdIpAddress>                 <--- correct
  <HrdTcpPort>7826</HrdTcpPort>                                <--- correct
  <HrdDatabaseName>F1VEV</HrdDatabaseName>   <--- Is this the correct name (Title) of your Logbook database?
  <ConnectionString>Provider=MySqlProv;Server=localhost;User Id=root;Password=(hidden);Database=mysql;Port=3306;</ConnectionString>  <---  check your Username, Password, Database and Port
  <LogbookExtract>0</LogbookExtract>                        <--- correct (0 means all contacts will be extracted from HRD Logbook during a database sync.
  <SqliteFileName>C:\Users\Utilisateur\AppData\Roaming\VK2BYI\QSORelay\My SQL F1VEV.sqlite</SqliteFileName>   <--- that is OK
  <AdifFileName>C:\Users\Utilisateur\AppData\Roaming\VK2BYI\QSORelay\log.adi</AdifFileName>                                <--- check that you have the same filename selected in JTAlert for "Log File" under the "Standard ADIF File" setting
  <EnableTracing>false</EnableTracing>
</AppSettings>

So double check the settings in the Connection Properties:



For comparison, here is my settings.config file configured to work with my MariaDB installation which is working fine for me:

<?xml version="1.0"?>
<AppSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <ReceiveIpAddress>127.0.0.1</ReceiveIpAddress>
  <ReceiveUdpPort>2333</ReceiveUdpPort>
  <HrdIpAddress>127.0.0.1</HrdIpAddress>
  <HrdTcpPort>7826</HrdTcpPort>
  <HrdDatabaseName>Test Logbook - Maria DB</HrdDatabaseName>
  <ConnectionString>Provider=MySqlProv;Server=localhost;User Id=root;Password=(hidden);Database=mysql;Port=3307;</ConnectionString>  <--- I use port 3307 for my MariaDB installation, as I have MySQL installed on 3306
  <LogbookExtract>0</LogbookExtract>
  <SqliteFileName>C:\Users\Chris\AppData\Roaming\VK2BYI\QSORelay\My Logbook.sqlite</SqliteFileName>
  <AdifFileName>C:\Users\Chris\AppData\Roaming\VK2BYI\QSORelay\log.adi</AdifFileName>
  <EnableTracing>false</EnableTracing>
</AppSettings>

I do not know what is preventing QSO Relay from being able to connect to your MariaDB logbook database.  But I suspect the problem may lie with a problem with MariaDB.  Make sure the database is working.

Maybe you could try using the standard Access database which should be fine unless you have many 10's of thousands of contacts.

73 Chris
VK2BYI


Re: QSO looging to latest HRD v780

f1vev@...
 

Hi  Chris and Antony 

Not much luck rebbot and re start from fresh still cam up with negative results  as described previously 

Antony perhaps you can email me (QRZ)  so I can mail my settings to you ?

thanks Jacques 
--
Ic 7300 -  Win 10 Pro  - WJSTX 1.8 rc2 - JTalert 2.10.1-  HRD 6.4.787 - Maria dB QSO Relay  1.7


Re: QSO looging to latest HRD v780

Antony
 

Hi,
Had some QSOs yesterday on FT8 using the latest versions of HRD and QSORELAY and all were logged in my Maria dB OK.
Regards, Antony G4CUS


Re: QSO looging to latest HRD v780

Chris VK2BYI
 

Hi Jacques,

That is strange.  The only difference between 1.6 and 1.7 was in the code that handles 'cached' contacts.  But I have looked at your session log file, and you have no cached contacts - which is how it should be normally.  So there should be absolutely no difference between 1.6 and 1.7 for you doing the database sync.

The session log file you captured only shows an attempt to synchronise databases, but is does show a couple of errors:
  • Object reference not set to an instance of an object. (La référence d'objet n'est pas définie à une instance d'un objet.)
  • Authentication to host 'localhost' for user 'root' using method 'mysql_native_password' failed with message: Unknown database 'f1vev'
There is something happening that is causing the MySQL (MariaDB) connection to fail.  But I can see from your 'settings.config' file, that you have specified the MySQL connection correctly.

I can't reproduce the problem here - I have tested 1.7 with Access, SQL Server, MySQL and MariaDB, and they all work fine as long as I have an empty Access database open at the same time.

Unless someone else who is using MariaDB can add to this, all I can suggest is you reboot and try it all again.

73 Chris
VK2BYI




QSO looging to latest HRD v780

f1vev@...
 

Hi Chris
 
HI unfortunately issue has cropped up again when using 1.7?
 
the contacts are logged in all files   but not transfered to HRD  the maria dB is ok  as coonect either through SQL or QSO Relay test I have sent the files.
 
Thanks Jacques 
-- Ic 7300 -  Win 10 Pro  - WJSTX 1.8 rc2 - JTalert 2.10.1-  HRD 6.4.787 - Maria dB QSO Relay  1.7


locked QSO Relay version 1.7

Chris VK2BYI
 

Please be advised that a new release of QSO Relay (Version 1.7) is now available for download at http://www.vk2byi.com.au/qsorelay/, or by selecting the Check for Updates... item on the QSO Relay menu if you are using a previous version of QSO Relay.

This version is a quick corrective update to the just-released version 1.6 that contained a minor defect, so I will repeat the changes here that were introduced in version 1.6, and include a description of the fix in this release:

  • v1.6: Added FT8 and JT4 to the set of modes that will be extracted from HRD Logbook during a synchronise database operation when filtered by the ‘JT Mode contacts only’ selection in the Logbook Extract drop-down listbox in the Options dialog;
  • v1.6: Added support for embedded carriage return/line feed characters in the Address field in the UDP datagram sent by JTAlertX.
  • v1.7: Fixed an error where the cached contacts file was not being parsed correctly. This is the only change from v1.6.

The latest version of Ham Radio Deluxe includes a fix in Logbook that now allows contacts to be added via the Logbook API that contain multi-line values in the Address field, using a back slash and lower case ‘n’ character sequence (\n) to represent the place where a line break should occur.

If you upgrade to version 6.4.0.787 (or later) of HRD, and QSO Relay version 1.7 (or later), you can now turn the ‘Log Address returned from an XML or previous QSO lookup’ option in the Logging node in JTAlert settings back on:



QSO Relay 1.7+ will now replace any embedded carriage return/line feed characters in the Address field with the newline place marker characters so that HRD Logbook will now correctly log the contact without any loss of data.

I would like to especially thank Mike (WA9PIE), Mike (K7ZCZ) and the rest of the team at Ham Radio Deluxe, for their efforts in working with us to resolve this issue.

73 Chris
VK2BYI


locked WARNING: Minor Defect in QSO Relay 1.6

Chris VK2BYI
 

Please be advised there is a minor defect in the latest release v1.6 of QSO Relay.

This defect will only occur under the following set of circumstances:
  • You log a contact and QSO Relay reports that it could not be logged in HRD Logbook because it is not running or responding.  In this situation, QSO Relay caches the contact so that another attempt can be made to log it later;
  • You start/restart HRD Logbook;
  • You select the Synchronise Databases... menu item in QSO Relay, so that it will try to log any cached contacts before synchronising the databases;
  • You have one or more cached contacts that contain a multi-line address field value.

In this situation, QSO Relay incorrectly reads the 'cached' contact(s), and you receive the following error message: "The given key was not present in the dictionary".

A new version of QSO Relay will be made available as soon as possible. I sincerely apologize for the inconvenience.

73 Chris VK2BYI


Re: QSO looging to latest HRD v780

Chris VK2BYI
 

Glad to hear that Jacques, and you are most welcome.

73 Chris
VK2BYI


Re: QSO looging to latest HRD v780

f1vev@...
 

HI everyone, just an update on topic above 

I took the opportunity of the new QSO Relay 1.6 and new GRD .787  to do a new install of QSO relay and all is now working fine  back to usual so not sure what happened on previous version mix but  all is  fine now  

Thanks you all  Jacques 
--
Ic 7300 -  Win 10 Pro  - WJSTX 1.8 rc2 - JTalert 2.10.1-  HRD 6.4.787 - Maria dB QSO Relay  1.6


locked QSO Relay version 1.6

Chris VK2BYI
 
Edited

Please be advised that a new release of QSO Relay (Version 1.6) is now available for download at http://www.vk2byi.com.au/qsorelay/, or by selecting the Check for Updates... item on the QSO Relay menu if you are using a previous version of QSO Relay.

This version includes the following changes:

  • Added FT8 and JT4 to the set of modes that will be extracted from HRD Logbook during a synchronise database operation when filtered by the ‘JT Mode contacts only’ selection in the Logbook Extract drop-down listbox in the Options dialog;
  • Added support for embedded carriage return/line feed characters in the Address field in the UDP datagram sent by JTAlertX.

The latest version of Ham Radio Deluxe includes a fix in Logbook that now allows contacts to be added via the Logbook API that contain multi-line values in the Address field, using a back slash and lower case ‘n’ character sequence (\n) to represent the place where a line break should occur.

If you upgrade to version 6.4.0.787 (or later) of HRD, and QSO Relay version 1.6 (or later), you can now turn the ‘Log Address returned from an XML or previous QSO lookup’ option in the Logging node in JTAlert settings back on:



QSO Relay 1.6+ will now replace any embedded carriage return/line feed characters in the Address field with the newline place marker characters so that HRD Logbook will now correctly log the contact without any loss of data.

I would like to especially thank Mike (WA9PIE), Mike (K7ZCZ) and the rest of the team at Ham Radio Deluxe, for their efforts in working with us to resolve this issue.

73 Chris
VK2BYI


Re: JTAlert shows incorrect log entries

Bruce Croskey
 

For the record, it still does some strange things, but to make it work I sync the log then turn the computer off and restart it then run the scan..If I don't do that, it does not read the log and marks everything as not worked... I have JTAlert set to track any mode and thought that that would mean that if I reset it to show JT65 ot FT8 or digital it would show those correctly but that is not the case... it shows those as snot worked even though any mode should include that info too... oh well, not being a computer guy, I just live with the mysteries hi hi
73, bc


Re: JTAlert shows incorrect log entries

Chris VK2BYI
 

Ah, that is great news Bruce!

I am glad you find the software useful, even if the journey has taken a little longer than you would have liked.

Thank you very much for the contribution.

73 Chris


Re: JTAlert shows incorrect log entries

Bruce Croskey
 

I found it !!!!! Thanks for all the help.. you are the greatest and I paypaled you


Re: JTAlert shows incorrect log entries

Bruce Croskey
 
Edited

I did exactly as you did above...and I see the QSO entry in the session log, I did the sync, I selected No QSL and did the scan when the scan finished, I see that all the tracked bands are highlighted in green and ALL say states needed is 50 and Previous is the correct number.... the scan is not seeing the log. When I use JTAlert it adds QSO's to the log perfectly including the address but when I scan, it seems to ot see the log at all.


Re: JTAlert shows incorrect log entries

Chris VK2BYI
 

No, this is simply the session trace reporting what contacts QSO Relay has extracted from HRD Logbook and is only displaying those fields that make a contact unique - i.e. Time On, Call, Band and Mode.  There are too many columns in the extract to list them all in the session trace file.
 
Maybe it will help if I go through this step by step...
 
This is the current status of my Wanted US State - I need ND, NE, VT and WY.

  • I add a QSO for a Vermont station in HRD Logbook using the call W1ZU, making sure that the State column is populated correctly in Logbook;
  • I enable a session trace so I can verify that the new contact is being extracted;
  • I select Synchronize Databases... menu option in QSO Relay;
  • I can see the contact for W1ZU that I just added is in the session log:
      ...
      2017-09-12 12:42:03.8899 Begin transaction
      2017-09-12 12:42:03.8899 Time On: 2017-09-12 02:39:44, Call: W1ZU, Band: 20m, Mode: RTTY
      2017-09-12 12:42:03.8934 Time On: 2017-04-03 05:09:00, Call: 4W/YB3LZ, Band: 20m, Mode: JT65
      ...
  • I can also check the ADIF file written by QSO Relay, and the full details of this contact is in the very last record in the ADIF file (I have highlighted the STATE field):
    ...
    <CALL:4>W1ZU<QSO_DATE:8>20170912<TIME_ON:6>023944<TIME_OFF:6>023944<FREQ:9>14.074000<FREQ_RX:8>0.000000<BAND:3>20m<BAND_RX:0><MODE:4>RTTY<RST_SENT:3>599<RST_RCVD:3>599<GRIDSQUARE:6>FN34ll<DISTANCE:5>16116<RX_PWR:1>0<TX_PWR:3>120<A_INDEX:2>11<K_INDEX:1>3<SFI:2>80<COMMENT:0><NAME:16>Scott R Anderson<QTH:14>Essex Junction<CQZ:1>5<ITUZ:1>8<PFX:2>W1<STATE:2>VT<DXCC:3>291<COUNTRY:13>United States<CONT:2>NA<MY_GRIDSQUARE:6>QF55mx<MY_CQ_ZONE:2>30<MY_ITU_ZONE:2>59<STATION_CALLSIGN:6>VK2BYI<QSO_COMPLETE:1>Y<QSLRDATE:8>20170912<QSL_RCVD:1>N<QSLSDATE:8>20170912<QSL_SENT:1>N<EQSL_QSLRDATE:8>20170912<EQSL_QSL_RCVD:1>N<EQSL_QSLSDATE:8>20170912<EQSL_QSL_SENT:1>N<LOTW_QSLRDATE:8>20170912<LOTW_QSL_RCVD:1>N<LOTW_QSLSDATE:8>20170912<LOTW_QSL_SENT:1>N<EOR>
  • I open Scan Log and Update in JTAlert, but you will see that although I have enabled the Wanted US State scan, I have set confirmation required by eQSL or LoTW before JTAlert will update the wanted status:

  • Because this contact has not yet been confirmed in HRD Logbook, after all it is just a test contact, I will temporarily check the No QSL Confirmation (Any Worked Station) checkbox, so that confirmation is not required and so JTAlert should update the wanted status:

  • I now perform a Scan Log and Update in JTAlert so that it will scan the ADIF file and update my Wanted Alert requirements;
  • After the scan completes and I apply the changes, I check Wanted US State and now VT is no longer wanted and is unchecked:


Perhaps you should check the settings on the Wanted US State scan and make sure that Enable this Scan is checked, and that you have set either No QSL Confirmation is required, or confirmation is required by one or more methods before the status will be updated in JTAlert.
 
I hope this helps.
 
73 Chris
VK2BYI
 


Re: JTAlert shows incorrect log entries

Bruce Croskey
 

I tried entering new QSO's in the HRD log from states I need...Did the sync then went to JTAlert and did the scan.... none of the entries show as worked....I ran the synchronise log and notice that all the entries are the same no matter what session I look at...I did find an older one and am sending you the screenshot... it does no show ant state data isthis why I cant get the states worked updated??