The ExcelDataConnector does not support write access.

Class library usage, coding and language questions.
carsonw
Posts: 178
Joined: Tue Nov 08, 2011 10:01 pm

The ExcelDataConnector does not support write access.

Post by carsonw » Tue Apr 17, 2012 7:43 pm

I saw the post below speaking about writing back to excel but I didn't want to post there in case it derailed that thread.

When trying to update data in our cache, we get the error in the subject above. Are there any plans for Ranorex to support this natively?

This functionality is incorporated in QTP (our other automation solution) and many of our tests are designed around this functionality being in place.

We've been trying to work around this issue by restructuring certain tests, but there is going to come a time soon where this is not possible and we will have to write back to Excel (even just the data in memory is fine, the sheet does not have to be saved/reloaded).

We aren't really keen on writing our own methods to interact with Excel, the idea was that we had an out of the box solution to do this for us (this is part of the reason we waited so long to purchase - we were waiting for the Excel connectors to come into place) but we didn't realize until recently that the data only flowed in one direction.

Hopefully this support can be added soon. Thanks!

Carson.

EDIT: Not sure if it's relevant, but the reason we use this quite a bit is we get data as a result of one test iteration, and then use it in subsequent iterations. For example, in iteration one, I might get back an order ID from the AUT, and I write that orderID back into my test data sheet. Then, subsequent iterations who have a reference to that cell, know what the newly created order ID is, and actions can be executed against that orderID generated from the previous iterations.
That's just one simple example, we use this sort of referencing functionality in our tests extensively so this is really going to hamstring us soon.

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: The ExcelDataConnector does not support write access.

Post by Support Team » Wed Apr 18, 2012 10:59 am

Hi,

Thank you for your feedback. I will add an issue to our internal TFS database.

Regards,
Peter
Ranorex Team
.
Image

carsonw
Posts: 178
Joined: Tue Nov 08, 2011 10:01 pm

Re: The ExcelDataConnector does not support write access.

Post by carsonw » Wed Apr 18, 2012 4:16 pm

Thanks kindly - does that mean we'll see this functionality in a future version? Basically we're avoiding writing these types in tests in Ranorex, but we'd like to drop QTP completely and to do so we'd need this functionality. Thanks again :)

Carson.

omayer
Posts: 458
Joined: Thu Oct 28, 2010 6:14 pm

Re: The ExcelDataConnector does not support write access.

Post by omayer » Wed Apr 18, 2012 6:23 pm

Carsonw, I do really need this feature , "iteration one, I might get back an order ID from the AUT, and I write that orderID back into my test data sheet. Then, subsequent iterations who have a reference to that cell, know what the newly created order ID is, and actions can be executed against that orderID generated from the previous iterations. "
Thank you,
Beginner
Tipu

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: The ExcelDataConnector does not support write access.

Post by Support Team » Fri Apr 20, 2012 11:04 am

carsonw wrote:does that mean we'll see this functionality in a future version?
Yes it should be in one Ranorex version, but I cannot tell you when this will be. Meanwhile you have to create your own method or class to perform this action.

Regards,
Peter
Ranorex Team
.
Image

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 3922
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: The ExcelDataConnector does not support write access.

Post by odklizec » Fri Apr 17, 2015 12:52 pm

Hi,

Sorry for reopening this old thread, but I guess the ExcelDataConnector still does not support write access?

I'm personally using CSVDataConnector to write data to CSV file, but I guess the same would be useful for people requiring writing data to Excel (like in this post)?

I tried to adapt my CSVDataConnector writing code to ExcelDataConnector and I found it's still not possible to use it for writing excel files.

Here is a quick code snippet...
string xlsOutputPath = System.IO.Directory.GetCurrentDirectory() + "\\file.xlsx";
Ranorex.Core.Data.ExcelDataConnector xlsConnector = new Ranorex.Core.Data.ExcelDataConnector("xlsConnector",xlsOutputPath,"Sheet1","A:A",System.Windows.Forms.CheckState.Unchecked);
Ranorex.Core.Data.ColumnCollection columnCollection;
Ranorex.Core.Data.RowCollection rowCollection;
xlsConnector.LoadData(out columnCollection, out rowCollection);
rowCollection.Add(new string[3]{"teststring_1","teststring_2", "teststring_3"});
xlsConnector.StoreData(columnCollection,rowCollection);
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: The ExcelDataConnector does not support write access.

Post by Support Team » Mon Apr 20, 2015 12:24 pm

Hi odklizec,

Unfortunately, we didn't implement this functionality until now. I will enter your request to our internal bug fixing system.

Kind regards,
Robert
.
Image

c676228
Posts: 176
Joined: Mon Apr 06, 2015 5:40 am

Re: The ExcelDataConnector does not support write access.

Post by c676228 » Tue Jun 09, 2015 6:44 pm

I add one more vote here!!!
We need write access for ExcelDataConnector too.
Like Carson mentioned, we also need this feature since the later test cases need to access data written from previous test cases.

Thanks odklizec for re-open this. I was going to open a new topic for this and came across this thread.
Someone did for me. :D

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: The ExcelDataConnector does not support write access.

Post by Support Team » Thu Jun 11, 2015 9:45 am

Hello all,

It would be great if you could give us further information on why you would need to write to an Excel file, instead of using e.g., a CSV file.

Thank you in advance.

Regards,
Robert
.
Image

krstcs
Ranorex Guru
Posts: 2683
Joined: Tue Feb 07, 2012 4:14 pm
Location: Austin, Texas, USA

Re: The ExcelDataConnector does not support write access.

Post by krstcs » Thu Jun 11, 2015 1:23 pm

In my opinion, if you need to manipulate data during the test, you should be using a database, not a flat file like CSV or XLS. It is much easier to write consistently back to a database, and any queries after the write will see the new information automatically.
Shortcuts usually aren't...

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 3922
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: The ExcelDataConnector does not support write access.

Post by odklizec » Thu Jun 11, 2015 2:14 pm

Here are my two cents ;)

While I understand krstcs' arguments about using DB as a data source, I personally don't like the idea of using DB, because, in my opinion, it would add unnecessary and unjustified complication to my test projects. Not to mention I'm not a DB guru ;) But it may be just me and the projects I'm working on. Simply, I have no meaningful use for DB.

At the moment, I'm using CSV files to store configurations (program/web settings). I'm generating these files directly from my test projects, using some custom methods. Simply, instead of validating ref. data with actual program state, I instruct tests to generate new ref. data.

By using CSV files, I'm ending-up with multiple files. It's not a problem, it works fine for me. But it would be nice to have an option to create xls file with multiple pages, instead of simple csv. If for nothing else, it would be much easier for sharing data with other people. I can't imagine a reasonable way of sharing data and results stored in DB. Not to mention some managers simply WANT excel files ;)
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

krstcs
Ranorex Guru
Posts: 2683
Joined: Tue Feb 07, 2012 4:14 pm
Location: Austin, Texas, USA

Re: The ExcelDataConnector does not support write access.

Post by krstcs » Thu Jun 11, 2015 3:00 pm

The point of a DB is to share data. They are designed expressly for the purpose of centrally located data that anyone who has access can get to.

SQL Server can export any query result to XLS or CSV.

As for not knowing SQL, I'll just say that it's something any tester should look into. If you are testing any system that uses a DB (which is pretty much any meaningful system under test), then you need to understand how to get data out of a DB so you can validate that it is being stored/read correctly. Otherwise you are just trusting that the developers did it right, which is very bad for a tester...

Using something because it works is one thing, using it because you don't want to learn something else is doing a disservice to yourself. You will be more knowledgeable and marketable by learning new skills, and DB skills are always in high demand.
Shortcuts usually aren't...

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 3922
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: The ExcelDataConnector does not support write access.

Post by odklizec » Thu Jun 11, 2015 3:30 pm

True, it's always good to learn new things. Regarding this I agree on 100%. However, using DB is not always the best option, no matter how good it is for storing and distributing data. Using simple CSV or Excel is often much easier, faster and in some cases even more reliable way to achieve the same effect.

I think you will agree with me that setting up and maintaining DB is not as simple as using csv or Excel stored in source control? In my opinion, using DB adds another level of complexity and new problems to already complex world of test automation. As I see it, DB makes sense only for large data sets. It simply does not make sense for small/medium scale data sources, where csv or excel could do the same work with much less effort and lower risks. But I may be completely wrong ;)

Anyway, I think this post is not the best place to discuss DB pros and cons in respect of test automation. The point of this post is to make sense of writing data to Excel using ExcelDataConnector. Quick search through this forum reveals multiple posts demanding writing data to Excel. Using ExcelDataConnector to do this would be a very nice and welcome option. Just my humble opinion ;)
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: The ExcelDataConnector does not support write access.

Post by Support Team » Fri Jun 19, 2015 9:48 am

Hello,

Thank you for your input. It's very much appreciated.

Regards,
Robert
.
Image

c676228
Posts: 176
Joined: Mon Apr 06, 2015 5:40 am

Re: The ExcelDataConnector does not support write access.

Post by c676228 » Tue Jul 21, 2015 7:54 pm

Is the feature for writing data to excel file loginDataConnector.StoreData(_columnColl, _rowColl)
implemented? What is the status?

I agree with Pavel. Not every tester/QA likes or is capable in manipulating data in database.
For them, excel sheets are much more straightforward, easy to view and much more info is available for one sheet.
Each row data in an excel sheet can represent one test case. While one sheet can combine all related test cases and run in a batch.