Problem with Postgres DAM Studio 4.3.2.1 non-unicode on Windows 10

Hi Doug,

Thanks for getting back on this so quickly. Memory seems to grow constantly, and when using binary bind variables I have a feeling this is causing the crashes I am seeing. At the moment Studio is using almost 700MB of RAM and still running, but as soon as I start inserting binary values, everything is fine for a while, and at some stage Studio just disappears. Perhaps someone else is aware of a newer Postgres DAM for Studio 4.3.2 that I could test with to see if this might resolve my issue.

Regards

Rudolf

Von: Doug Easterbrook [mailto:doug@artsman.com]
Gesendet: Freitag, 27. November 2020 17:17
An: OmnisDev List – English <omnisdev-en@lists.omnis-dev.com>
Betreff: Re: Problem with Postgres DAM Studio 4.3.2.1 non-unicode on Windows 10

hi Rudolf

I’m going back in memory on this and I believe you wold be right.

Many moons ago, we had random crashes in postgres with studio 4.2 (earlier than your version) and I spent 4 long days at a customer site on the issue (and a bunch of time after) I did a lot of debugging. and as I recall, part of the process was that we were then given a dam that implemented the sys() function that dumps out the sql from the dam to a log file.

I matched up a whole lot of things — and we found a definite memory leak. we could see it using a loop (like you did) and it provided Omnis support with a librry at the time that showed memory usage rising in activity monitor.

I do not thing it was fully resolved in studio 4.3 — since we jumped to Studio 5.x and unicode. and that helped cure our problem.

Doug Easterbrook
Arts Management Systems Ltd.
mailto:doug@artsman.com
www.artsman.com
Phone (403) 650-1978

On November 27, 2020, at 7:46 AM, Rudolf Bargholz <rudolf@bargholz.ch<mailto:rudolf@bargholz.ch>> wrote:

Hi,

I have been struggling the past few days trying to get Studio 4.3.2.1 non-unicode on Windows 10 to work with Postgres (tested and reproduced with Postgres 12 and 13 so far). The issue is that the DAM seems to have a memory leak, and at some point Studio crashes when executing simple INSERT SQLs.

Here the code. I have simplified it down as far as I could while still having the issue:

Working message Hotel {[#1]}

For #1 from 1 to 1000000 step 1

Redraw working message
Do cPgSqlDamObj.$commit()

Do lr_tohotels.$clear()
Calculate lr_tohotels.hotelkey as lHotelList.HOTELKEY

Begin statement
Sta: INSERT INTO
Sta: tohotels
Sta: (
Sta: hotelkey
Sta: ,inserted_at
Sta: ,updated_at
Sta: )
Sta: VALUES
Sta: (
Sta: @[lr_tohotels.hotelkey]
Sta: ,CURRENT_TIMESTAMP
Sta: ,CURRENT_TIMESTAMP
Sta: )
Sta: ON CONFLICT (hotelkey) DO UPDATE
Sta: set
Sta: hotelkey=@[lr_tohotels.hotelkey]
Sta: ,updated_at = CURRENT_TIMESTAMP
Sta: returning (id);
End statement
Do cStat.$execdirect()
Do cStat.$fetchinto(lr_tohotels.id<lr_tohotels.id>)

End For

The loop runs and runs, and the memory of the omnis.exe keeps on growing, never going down. The more different SQLs that are called, the faster Studio crashes. No error is displayed. Omnis just disappears after a short period of freezing up.

I have tried with or without transactions. The following also does not seem to help, executed after an SQL:

Do cPgSqlDamObj.$clear()
Do cPgSqlDamObj.$reset()

Tried using $prepare() and $execute(), and then just $execdirect(), but in both cases the memory usage keeps growing till Studio crashes.

Tried using object references instead of object variables, but the behavior is the same for both types of variables.

Executing a $logoff() and a renewed $logon() also did not help.

Is anyone aware of any such issues with memory leaks in Studio 4.3.2.1 in conjunction with the Postgres DAM? Is there any workaround to the issue, or is there perhaps a replacement DAM that I could try to see if this would resolve the issue?

The version number displayed in the xcomp PGSQLDAM is “1.0” .

Upgrading Studio would mean a rewrite of our app, and that is unfortunately not possible at the moment due to the cost of development and the cost of new runtimes.

Regards

Rudolf Bargholz
_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com

_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com