I think the problem is your UNION ALL in the query. From the docs:
This means that a query requiring a copy of data, such as one using an ORDER BY clause or UNION DISTINCT, will issue an error and not be allowed.
In addition, you may want to consider this advice from the docs:
When using eof-delay, consider using a simple query to avoid blocking of rows. When rows are blocked for data transport efficiency, rows won't be returned until the block is full. Therefore, you should decide whether you favor data transport efficiency or moving events as soon as they occur.
You probably want to specify BlockFetch=0 in the DSN or the connection string to disable internal block fetching by the driver or adjust the driver's block size with BlockSizeKB. The default is BlockFetch=1 and BlockSizeKB=256K, so the first fetchnext() will wait until there's 256K of data to return. This could take a very long time, especially if there is little activity on the system.
In addition, you do not need to write your own generator as PyODBC cursors are iterators: https://github.com/mkleehammer/pyodbc/wiki/Features-beyond-the-DB-API#cursors-are-iterable Although, there still may be a benefit to doing so, utilizing fetchmany() to fetch blocks of rows eg. 5 or 10 at a time then return 1 at a time from the generator:
while True:
rows = cursor.fetchmany(5)
if rows is None:
# Should never happen, since HISTORY_LOG_INFO never returns EOF with EOF_DELAY set
break
for row in rows:
yield row
This would be more efficient at the cost of potential delays waiting for the block to fill. For a syslog tool, this may not be desired, but that's up to you.
I was able to run your script successfully after I changed the query to remove the UNION and set BlockFetch=0 (also needed to add EOF_DELAY, which was not specified but I'm guessing that was just from messing around with it before you uploaded it). I did see new records coming in every so often (easy to test using isql to connect over ODBC, which causes a CPIAD09 message; or use SNDMSG TOUSR(*SYSOPR) so it is possible to do over ODBC.
------------------------------
Kevin Adler
------------------------------
Original Message:
Sent: Wed August 04, 2021 09:04 AM
From: Glenn Robinson
Subject: Using python with QSYS2.DISPLAY_JOURNAL and EOF_DELAY
Here's the test script I'm using at the moment.
------------------------------
Glenn Robinson
------------------------------
Original Message:
Sent: Mon August 02, 2021 05:02 PM
From: Kevin Adler
Subject: Using python with QSYS2.DISPLAY_JOURNAL and EOF_DELAY
When using Python ibm_db or PyODBC, how are you fetching the data? When using EOF_DELAY, the table function will never return EOF, so if you use fetchall() or any fetch function which expects to get EOF before returning data, you could encounter this situation.
------------------------------
Kevin Adler