<div dir="auto"><div>Resending as requested. </div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif;font-size:12.8px">Just as an update. I identified the cause for my computer locking up. Turns out to be a KDE Desktop wallpaper component I had enabled and not KMM.</span><div style="font-family:sans-serif;font-size:12.8px" dir="auto"><br></div><div style="font-family:sans-serif;font-size:12.8px" dir="auto">I have continued to use 4.8.1.1 since I have not been able to get 5.0 to compile on my box. I am still seeing the 6 per manual entry insert/update via ledger and I have been able to time the OFX import process more accurately with my normal use to approximately 1 minute per processed entry. Also it is taking about 16 sec to combine entries entered via OFX update and my manual entry when I select them and click on "Match". I can sort of deal with the delay for manual entry if I have to but I can't always update my account via OFX on a small increment of time routine. I am starting to thinking that will need to make OFX account updates as batch operation that run over night. <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;background-color:rgb(255,255,255)">Is there anything I can do to speed up this process? </span></div><div class="gmail_extra" dir="auto"><br><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text"><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 26, 2018 at 4:28 AM, Tony Bloomfield <span dir="ltr"><<a href="mailto:tonyb.lx@ntlworld.com" target="_blank">tonyb.lx@ntlworld.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As the original developer of the DB interface, I'm interested in this<br>
thread. I had a similar problem to the OP when I tried 4.8 under<br>
Windows, but when I tried looking a bit at the code, I found it had<br>
changed so much since I was last involved, and unfortunately didn't have<br>
much time available to try relearning!<br>
<br>
But as a general point, the original design tried to distinguish between<br>
application version updates and database version changes (though<br>
normally these would go step in step). To this end, the kmmFileInfo<br>
table contains a 'version' and a 'fixlevel' column; IIRC, the former<br>
indicated the database version and the latter corresponds to the<br>
application version. If the database layout changes in any way, the<br>
database version number should be updated. When an existing  database is<br>
opened, the database manager should detect the change in version and<br>
create/delete/alter any tables/columns as required.<br>
<br>
As for naming a column 'order', I'm at a loss to understand how that<br>
worked, because I'm pretty sure that's a reserved word in all versions<br>
of SQL!<br>
<span class="m_-2239141220676458903HOEnZb"><font color="#888888"><br>
--<br>
<br>
Cheers<br>
TonyB<br>
<br>
</font></span></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div>