Error Connecting to MySQL DB 4.8.1.1
El Cas
eaglexboy at gmail.com
Sun Feb 25 23:37:34 UTC 2018
It appears it finished processing my entries. I was able to start up the
application and it logged in and loaded my database.
First off, thanks for adding the Tags feature as adding the tags in memo
was not the best way to search and group transactions. The one thing I have
noticed is that it's take a bit longer to switch between sections and
accounts in the ledger compared to 4.6.6 (from ~2 sec to ~6sec). I have the
filter set to only show the past two months. To see if it would make a
difference I changed the filter to the start of month (so it only show the
past 25 days) but the response time remained about the same. The only thing
I saw in the terminal was *KMyMoneyPlugin::PluginLoader::
createInstanceFromService returned 0 for SEPA orders with error Could not
find plugin 'SEPA orders' for application 'kmymoney' *when I updated the
filter. I don't know if this delay is due to the way it communicates with
DB now vs 4.6.6 or if something else is going on. I made sure to not have
anything else running that would make it appear that KMM was running slow.
At its peak KMM used 8% of my CPU and 137Mb of RAM.
System specs
Processor: AMD Fx-4350 Quad Core
Memory: 32Gb Ram, 64 Gb Swap
OS: Kubuntu 17.10 (Kernel 4.13.0-36)/64-Bit
Is there something I can do to speed up or check why it's taking longer
then normal?
On Sun, Feb 25, 2018 at 3:39 PM, El Cas <eaglexboy at gmail.com> wrote:
> So after running for 11 hours my box became unresponsive. I could move the
> mouse and the cursor reflected the move but that was all I could do. I
> tried to SSH and I got a response to the connect attempt but never got
> prompted for password (which would make sense seeing how I could only use
> the mouse on it).
>
> I have 32,248 rows in *kmmsplits* which is a good amount but I don't know
> how exactly the code cycles through them during 2 < 4. If it loads them in
> memory then this would explain why my box appeared to be unresponsive. I
> tried to build it with debug enabled but I can't seem to build i. I keep
> getting the following two errors.
>
> /kmm/kmymoney/libkdchart/src/KDChart/Cartesian/KDChartCartesianAxis.cpp:
> In member function ‘void KDChart::TickIterator::
> computeMajorTickLabel(int)’:
> /mnt/WorkingFolder/temp/kmm/kmymoney/libkdchart/src/KDChart/Cartesian/
> KDChartCartesianAxis.cpp:276:46: *error*: conversion from ‘QMap<double,
> QString>::iterator’ to non-scalar type ‘QMap<double,
> QString>::ConstIterator {aka QMap<double, QString>::const_iterator}’
> requested
>
> *m_dataHeaderLabels.lowerBound( slightlyLessThan( m_position )
> );
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
> /mnt/WorkingFolder/temp/kmm/kmymoney/libkdchart/src/KDChart/Cartesian/KDChartCartesianAxis.cpp:
> In member function ‘void KDChart::TickIterator::operator++()’:
> /mnt/WorkingFolder/temp/kmm/kmymoney/libkdchart/src/KDChart/Cartesian/
> KDChartCartesianAxis.cpp:306:76: *error*: conversion from ‘QMap<double,
> QString>::iterator’ to non-scalar type ‘QMap<double,
> QString>::ConstIterator {aka QMap<double, QString>::const_iterator}’
> requested
>
> *QMap< qreal, QString >::ConstIterator it = m_annotations.upperBound(
> m_position );
> ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~*
>
> I ran *cmake -D CMAKE_BUILD_TYPE=Debugfull ..* and *make* as the
> README.cmake said to do. Am I missing something?
>
> Is there another way to monitor what is going on during the looping of
> records in 2 < 4?
>
> While I await for a response I will try to run it again and direct all
> output to a file so that if it hangs again I can at least see what it spit
> out on the terminal.
>
>
> On Sun, Feb 25, 2018 at 9:53 AM, Thomas Baumgart <thb at net-bembel.de>
> wrote:
>
>>
>> On Sonntag, 25. Februar 2018 04:51:18 CET El Cas wrote:
>>
>> > On Sun, Feb 25, 2018 at 2:31 AM, Thomas Baumgart <thb at net-bembel.de>
>> wrote:
>> > > Having the DB on a separate server should not make a difference. All
>> > > communication (incl. structure updates etc) between KMyMoney and the
>> SQL
>> > > DB is
>> > > via a communication link.
>> > >
>> > > I am not sure, if bringing in 5.0 at this point is a good
>> alternative. You
>> > > might have a trouble to go back to 4.8 unless you want to stick with
>> 5.0.
>> > > Since you're building from source also, use the 5.0 branch, not
>> master. It
>> > > already contains a couple of bug-fixes over the released 5.0 version.
>> >
>> > The reason I was using Kubuntu 18.04/KMM 5.0 was because 18.04 is
>> > scheduled to be released in April and if this fixed my problem I would
>> just
>> > going to completely upgrade my system to 18.04/5.0 ahead of scheduled.
>> >
>> > So while using Kubuntu 18.04/KMM 5.0 I was getting a database user
>> error so
>> > I just temporarily granted the username I am using for KMM all
>> privileges.
>> > I created an empty test account and proceeded to save as DB. I put in
>> the
>> > required information and when I clicked on Ok. Got the error below.
>> >
>> > *Error in function int MyMoneyStorageSql::open(const QUrl&, int, bool) :
>> > opening new database*
>> >
>> > *Driver = QMYSQL, Host = X.X.X.X, User = kmymoney, Database =
>> /newkmymoney*
>> >
>> > *Driver Error: QMYSQL: Unable to connect*
>> >
>> > *Database Error No 1049: Unknown database '/newkmymoney'*
>> >
>> > *Text: Unknown database '/newkmymoney' QMYSQL: Unable to connect*
>> >
>> > *Error type 1*
>> >
>> > *Executed: *
>> >
>> > *Query error No -1: *
>> >
>> > *Error type 0*
>> >
>> > I checked the DB server and the Database was created but it was empty.
>> >
>> > So I went back to Kubuntu 17.10/KMM 4.8.1.1 (from source) and repeated
>> the
>> > same process. This time the test database was created and the tables
>> were
>> > created. I decided to attempt to open my original database and got the
>> same
>> > error I reported in my first email.
>> >
>> > As for difference between 4.8.1.1 vs 4.6.6 I found the following
>> >
>> > 4.6 has 24 tables vs 23 tables on 4.8: *kmmtmpfileinfo*
>>
>> That's not a problem. This seems to be some leftover from a previous run
>> (probably the creation of the new columns in kmmfileinfo). You should be
>> able
>> to drop that table.
>>
>> > And the following tables have extra columns
>> > Version tablename field name
>> > type Null? Default Value
>> > 4.8 *kmmfileinfo* hiOnlineJobId bigint(20) unsigned
>> > YES NULL
>> > 4.8 *kmmfileinfo* hiPayeeIdentifierId bigint(20) unsigned
>> > YES NULL
>> > 4.8 *kmmschedules* lastDayInMonth char(1)
>> > NO NULL
>> > 4.8 *kmmsplits* costCenterId varchar(32)
>> > YES NULL
>>
>> Those are the new columns that were added in 4.8. So that looks about
>> right
>> and 4.8 cannot start w/o them.
>>
>> > I made a back up of my current DB and added the missing fields to the
>> > corresponding tables and I was able to open the Database. It proceeded
>> load
>> > and when it reached 97% it began to do *testing fileFixVersion*. During
>> the
>> > 0 < 4 run it performed several *Fixed interest action in XXXX*
>> actions. It
>> > then ran *testing fileFixVersion* *1 < 4 and 2 <4 *has been running for
>> a
>> > long time (almost 2hr as of this email). I don't know how long the
>> testing
>> > normally takes but I will let it continue running and see how long it
>> takes
>> > to finish.
>> >
>> > I am going to check on it when I wake up. I will report any progress, or
>> > lack there off.
>>
>> filefix 2 < 4 is doing the following according to the source code:
>>
>> // scan the transactions and modify transactions with two splits
>> // which reference an account and a category to have the memo text
>> // of the account.
>>
>> filefix 3 < 4 is doing the following:
>>
>> // make sure each storage object contains a (unique) id
>>
>> That is just a single operation and should not take long.
>>
>>
>> I can't tell you anything about the speed. Usually I use KMyMoney with a
>> GPG
>> encrypted XML file and not a database backend.
>>
>>
>> --
>>
>> Regards
>>
>> Thomas Baumgart
>>
>> https://www.telegram.org/ Telegram, the better WhatsApp
>> -------------------------------------------------------------
>> You cannot strengthen the weak by weakening the strong.
>> -------------------------------------------------------------
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20180225/d769c3d9/attachment-0001.html>
More information about the KMyMoney-devel
mailing list