How could we export a table using QV web interface?

[#1]

Hi:

We need to make a button to our users to export a table object tto a .csv file.

We've found the correct code in the community but it seems to be Visual Basic.

sub export_data

Set Elemento1 = ActiveDocument.GetSheetObject("CH62")

Elemento1.Export "C:\ExportFile.csv",";"   

end sub

Our users use QV web interface not the client application and doesn't work visual basic export command in web interface.

Does anyone know how to make a button to export table data (it's indifferent in wich format - txt, csv, ...-).

We've tried to export de table data with right buttom and using export option but the table is big and it doesn't work.

If we use client appilcation there's no problem in exporting it but if we use web interface there's no way....that's why we want to try to use script code...

Thanks.

[fosuzuki]

Hi,

I assume that when you say 'web interface' you're talking about AJAX. I developed an app which works fine under IE Plugin.

But if the right-button export isn't working, probably the macro export function will not work. You should set a calculation condition to limit the number of rows of the table so that the right-button export works fine.

Hope this points you in the right direction.

Regards,

Fernando

[#3]

Hi Fernando:

Thanks for your help.

You're ok....we use AJAX.

Probably as you tell us, if the right-button doesn't work, the macro export function will not too...but we expected the opposite...

The problem we've is our user doesn't want to limit the number of rows so we've a huge problem.

The total amount of rows is 700.000 so we think it shouldn't have to be a problem for Qlikview...(it normally manages more rows)

We've tried to reduce all expressions and, in fact, we have only a simple expression

=num(mid(LAST_CARD,4,9))

so we don't know what to do to export table content...

We've a temporaly solution...user can open Qlikview document from server directly with Qlikview client not using web interface and it works fine...but we think that's not the properly solution.

Regards.

[fosuzuki]

Hi,

Forgot to mention that the macro function will not work in AJAX (as-designed by QlikTech...).

I tested some right-button exports via AJAX of a simple table box, 12 columns with no expressions:

a. with approx 60k rows, it worked well, but the resulting file had 16MB.

b. with approx 350k rows, It also worked, but took more than 1 minute, and at the end I could not download the resulting file, it showed me the content as CSV text inside another window...

(interesting: I suspect that if you try to export more than 65k rows, you can't download the resulting file, it will function as b. This may have to do with the Excel 2003 limitation of 65k rows...)

I also tried to export the same table box via a macro with IE Plugin:

a. with approx 135k rows, it worked well and generated a 30MB file

b. with approx 350k rows, my macro crashed! (maybe because my virtualised test server has only 2GB memory...)

when I said: "if the right-button export isn't working, probably the macro export function will not work",  I meant that the first is certainly more optimized than the macro function. The above testings kinda proved that, the macro function wasn't able to do it....

But I can see some options:

1. if the access must be via AJAX, create an Extension to export to a CSV file. I've never done that but I'd guess it is possible. I wish I could give you an example...

2. instead of accessing the app thru QV Desktop, use IE with IE Plugin and the macro function. But I'm not sure if it will be able to deal with the 700k rows. I guess it will depend on the user's and server's hardware.

3. Convince the user that he doesn't need an export with 700k rows. What is he going to do with this huge amount of data ? If he is going to analyze it, it is certainly better to do it inside QlikView...

4. If the user really need this amount of data, isn't it possible to migrate this Excel export to a transactional system via a custom report/export?

Sorry, I'm not really helping you...

Regards,

Fernando