topic Designer, allocated memory exceeded in QlikView

Designer, allocated memory exceeded

Sun, 24 Jan 2010 17:39:35 GMT

I have some data shown in a pivot table with cycling groups for the dimensions. I run it on a 64 bit W7 and have 8GB RAM installed, when running the Qlik almost 5 GB are free.

Data displays but when I change the date dimension from year to week (even with data for a single day) the memory error occurs. It also does not go away by undoing the selection, I have to reload the qvd to get the data shown again.

Juerg

Designer, allocated memory exceeded

Sun, 24 Jan 2010 17:53:23 GMT

On further investigation found that the group item formula for serviceday must be responsible.

I need to show the date in format DD.MM.YYYY and I used the formula =date(Serviceday,'DD.MM.YYYY') in the group item definition.Removing this formula and using Serviceday only works fine. As my serviceday is a date how can I format it in the dimension to suppress the 00:00:00 time?

Noticed also in other cases that I really miss a "Number" formatting for dimensions in tables, they seem to exist only for expressions?

Juerg

Designer, allocated memory exceeded

Mon, 25 Jan 2010 13:12:45 GMT

Hi,
as you've already dicovered the formatting takes up a lot of memory. Instead I would suggest that you create a new field in the load statement i.e.

date(Serviceday,'DD.MM.YYYY') as DisplayedServiceday

The above would enable the object to be shown without allocated memory exceeded, since the calculation already is done in the script.

Good luck,
Jonas

Consultant at Optivasys | www.optivasys.com

Designer, allocated memory exceeded

Mon, 25 Jan 2010 15:04:34 GMT

Hi Jonas

Thanks, I have tried to load the Service_date with

date(Service_Date,'DD.MM.YYYY')

it look however that Qlik still looks at it as a date and shows the zero time values in the dimension

Jürg

Designer, allocated memory exceeded

Mon, 25 Jan 2010 16:11:26 GMT

Hi,
that seems odd, but I know dates kan be tricky. Try looking into the date#() funktion and how you can combine this to get rid of the zero time values. Otherwise; a quick and dirty way of solving it could be using

left(date(Service_Date,'DD.MM.YYYY'),10) as Service_Date

Not the right way, be problably solving your issue 😉

//Jonas

Designer, allocated memory exceeded

Wed, 06 Oct 2010 08:11:09 GMT

To avoid memory problems it might be necessary to move the formatting of date values into the data script.

But what can I do, when the user is able to change the language of the application including the change of the date format from (e.g.) DD.MM.YYYY to MM-DD-YYYY?

For this case I use something like

date(<field>, $(='DateFormatTime_'&(NLS))) which works BUT then I have the memory problems.

Regards,

Christian

Designer, allocated memory exceeded

kji — Wed, 06 Oct 2010 08:50:10 GMT

You should be able to set the number format for your field on the document level and not have to change anything in the script.

Designer, allocated memory exceeded

Wed, 06 Oct 2010 09:05:38 GMT

Johan,

I use the formular mentioned in my last post in the charts. When I modify the NLS variable the language switches from one to another. Everything works fine. Exception: The date fields in the dimensions of pivot tables. In table charts I can move the date field into the expression area and I have no memory problem. Although from the semantic point of view it is only a workaround and not always a perfect solution.

Christian

Designer, allocated memory exceeded

jonathandienst — Wed, 06 Oct 2010 09:17:59 GMT

You may not realize this, but the Date function does not change the internal numerical date, it only chamges the dispaly fomat. You can verify this by putting this expression into a text box =Num(Date(Now(), 'DD.MM.YYYY'))

To get rid of the time component, you should say

Date(floor(Service_Date), 'DD.MM.YYYY')

Jonathan

Designer, allocated memory exceeded

Wed, 06 Oct 2010 09:32:06 GMT

Hi Jonathan,

I know that the date function only changes the display format.

As described I have a memory problem with date fields in pivot tables and table charts.

Regards,

Christian