Hi Experts,
Earlier we were using Export SQL to Excel for generating the Excel from the db having 387 columns.
This particular service has got deprecated, how can we get this undepreciated or if there is any other workaround to generate the same.
Tried using Export Data Store Entity to Excel but it not working beyond 50 columns, when trying to break the colomn into set of 50 and then trying to right in next 50 column the previous column data is getting deleted.
Discussion posts and replies are publicly visible
Do you mean 387 rows? Or do you honestly mean that each row contains 387 named data elements?
Its 387 columns David, rows are more than 50K.
Export data store entity to Excel have limitation of 50columns hence can't use that smart service.
Also to confirm, is this a one-time data load, or are you building a process to import this massive excel file regularly?
Yeah having some more information would be helpful for us here. Why do you need all those columns? What are you doing with the data? There are other ways of getting data out of Appian that may be better depending on your use case.
Also, I was thinking regarding your other thread of importing this massive file. Will a CSV export not suffice? But yes, more details the better.
Hi Chris,
This will be weekly import process, I have thought on following approaches for importing the data,
1: Reading the data with readexcelsheetpaging() function and then transform it into custom data type and then write it to db using Write to data store entity, with this approach we are able to contain our RequestId in the records. Here problem is when the data set it to large it brings down the server
2: For larger data set I'm are trying to use the same smart service in a script task with batch size of 1000 row at a time, after writing it to db I'm chceking if it last batch is matching the count, if not then looping back to script task to read next 1000 lines and transform into cdt and then write.
3: Exporting the data to a staging table using Export Excel to Db and then moving data from staging table to main table along with Request Id.
Please suggest if there can be any better approach.
Not that this is a "supported" answer or anything, but last I checked, Export SQL to Excel still works just fine despite being deprecated.
Hi Mike,
Thanks for your response, I tried to use the same, its working fine but when I'am trying to make use of some base template which have some colored coded cells and formula its giving below error..
Export SQL to Excel was working fine till version 2.0.0 of Excel tools, currently we are on version 2.2.0 of Excel tools and Appian 20.4...could it be a possible reason..?
Bansh Patel
I'm really not sure, I assume that depends on the template you're trying to feed in. I don't know if any behavior was altered in the versions of excel tools which would affect this. For your template I'd double-check that it's freely editable by a user opening it in Excel, etc, but after that I'm not sure what to suggest. Maybe making a new copy of the template could help.
I honestly think that the real problem, much as you might not want to admit it, is that you have a database table with 387 columns.
I really wish there was a way to write 387 in all caps. 387! That's beyond incomprehensible. That should be about 7 or 8 tables. The reason export to excel is limited to 50 columns is because you really should be limited to 50 columns too. I think Appian might be justified in upping the cap to 100, for those cases where one table has to go 65 or even 78, but no one should ever actually reach the cap of 100 columns in a single table.
You are going to face problems of all kinds from all sides, and your project is going to be painful to update or maintain, possibly quite painful to use, unless you refactor that.