Further to this, sometimes this results in the application pool crashing. Lx

Hi Laurence, 10 seconds for a single form submissions, that's huge ...  Does the umbraco backend also perform this slow ?

Umbraco backend is fairly speedy, trying to get my head around why this is happening now. Will let you know if I find anything, Lau

I have also experienced this issue, we have an installation of Contour with two forms, one of the forms doesn't have this issue and another one does, as soon as I choose year or decade it stalls on "processing", however when set on month there is no problem paging through all the records (there are only 40).

Tim, if a screen capture would help with this, let me know.

Thanks for the extra details, will try to reproduce

@Laurence, does it happen with all forms in that installation?

Not sure, the site is only driving one form.

Will replicate on to local and setup a few different forms and see if I can get this problem again.

I maybe shooting in the dark, but could it be that it is a client side issue (e.g caused by the browser), not responding properly, which then causes the request to hang and crash? I say this as performance is considerably better in Firefox than it has been in Safari.

Does Contour query the DB directly, or does it use a XML cache? /Laux

Further to this, although performance on this install is slow than I would like, there is an issue when using Safari on the Mac. Will post back version, etc (it is not the latest version for sure).

Laux

The form which we have an issue with with has 42 submissions in the last year, in order to get the "processing...." frozen message, we can do two things.

1. First choose year (or decade) and reload, then choose 50 more more in the show menu (10, or 25 work with no problem and allow paging)
2. First choose 50 or more in the show menu then choose year (decade)

The other form in this installation of Contour has 113 entries in the last year and all filter options work fine.

Jeavon

Querying via XSLT also causes performance issues. /Lau

Using the export function on the top left of the form throws an System.Web.HttpException: Request timed out.

Okay I've had a chance to look at the issue in a tiny bit more detail.

The issue is caused by either large amounts of entries or columns. 

A very dodgy work around is turning all the columns off, loading in the data and then turning one on at a time. With a form which has 48 fields, I can load around 5 columns at around 300 records before Contour crashes the database. Even this takes around 5 minutes to complete. 

Guys what can I do to help? I've now had a chance to test this on 2 different systems and its not a system unique bug. I am more than happy to sink time into trying to fix this and improving Contour. 

Lx

So I would say this issue would be with;

/plugins/umbracoContour/webservices/records.aspx?

Hi Laurence, would it be possible to share your db ? That way I can try to find out where the performance issue is located.

You can just mail the details to tg at umbraco dot dk

Thanks!
Tim

Hi Tim,

Just wondering if there has been any progress with this (we have a client who is slightly frustrated about not being able to export their form data)?

Thanks,

Jeavon

@Jeavon,

Yes to resolve this simply roll back  /umbraco/plugins/umbracocontour/xslt/excel.xslt to this version:

http://dl.dropbox.com/u/14228187/excel.xslt

Cheers,
Tim

Hi Tim,

That doesn't seem to have helped in our case, still get a frozen "Processing......."?

Thanks,

Jeavon

@Jeavon,

That's the records viewer, the fix is for the export (if you hit the export button in the menu)

Another big and lovely ask would be that the export following the order of the fields on the form, not some random order!

Guessing I can do this in that XSLT though? Will have a look on Monday.

Lx

Yeah think it's a-z currently, but can be done in xslt, will see if I can easly add a new export option

Yep it is, been having a look over the weekend myself.

Am I right in thinking the reason why the XSLT extensions for Contour are slow (on long & complex forms) is because its directly querying the database?

Would it not make sense to use some sort of helper which created a XML Cache of the data? Then you could quickly manipulate the data. 

Just a thought really, Laurie 

@Tim I'm not sure that helps as we can't get a view that displays all the records within Contour as it gets stuck? However as a short term solution, we added the excel.xslt to a hidden page and it generated the csv values for all records on the page without any issue so we were able to copy and paste it and send the complete data to our client.

Thanks,

Jeavon

Jeavon, not sure if it helps. But Safari reports the script as being unresponsive and asks if you want to kill it, if you keep clicking continue to keep the script alive, even though the browser is completely locked up, you can eventually get all the records up on the page. 

I think its just a case of the query taking a long time to return the data. (hence my comment above above)

Laux

That is strange, I don't get the alert about killing it in Safari (Win 7) it just waits and waits.......

Just a quick bit of feedback, a present the excel.xslt sorts the fields in the form alphabetically.

Is there any end-user who would actually want the output like that? Surely it needs to reflect the sort order on the form? (or have a switch to allow easy changing)

On a completely separate note, it would be damn cool if you could import/update from a csv/xml/excel file. 

Thanks for the suggestions Laurence, I'll add this to our issue list.

Good point about the sort order in the export( I'll try to add one in the next maintenance release).

Also updated mine to export the GUID. That way if you are doing fancy shenanigans in Excel you've got something unique to reference against. Lx

Hi Laurence and Tim,

After a very drawn out forensic investigation we have tracked the freezing issue back to a solitary slash entered into a text field during testing! We manually updated the xml in the UFRecordsXml table to replace the content with the slash to remove it and now all filtering options work again! There must be a tricky little bug in there somewhere for you Tim!

Regards,

Jeavon

Thanks for the info Jeavon, will reproduce and fix!

No problem Tim, if you need a db backup please let me know.

Not to revive a dead thread or anything, but what's the status on the column sort option? It makes more sense to keep it sorted in the order that appears on the form.

One example where this is applicable is on a form that has more than one field with the same name, ie "Other". Sorted alphabetically, the values get lumped together and are not read in context.

is working on a reply...