Export to CSV not exporting all data? - D-Tools Forum

Jack Frost · 01-09-2008, 12:58 AM

I spoke to DT support on this and could not get a conclusive answer. When I use the excel export function in MMPD, the resulting file does not have the I/O's of the products.
The DT Support rep basically told me he did not know of any other way to export the data, and the export function in the MMPD does not seem to have any settings, options or adjustments that I can find. So why is this happening?

This looks like a bug in the export code to me.
Please advise.

ty.
J.

SenoS · 01-09-2008, 04:25 PM

This is more of a feature request than a bug. There is currently no function to map what fields export to Excel. I have submitted this as a request to our devo team for consideration for a future release. Out of curiosity, do you feel that editing the I/Os for a product is easier in an Excel spreadsheet using semicolons than it is within SI 5? If you sign a non-disclosure agreement (NDA) http://www.d-tools.us/faq.php?faq=ne...ew_faq_item502, Support will send you the password to the MasterTable.mdb file and you can edit directly in Access if you wish. Of course, modifying a database manually can be hazardous so be sure to make a backup copy of your database prior to opening it.

fryeguy · 01-10-2008, 06:27 PM

I edit data in a specially formatted spreadsheet that doesn't require semicolons. A script converts this data to the semicolon delimited format.
I find it much easier to work in an environment that allows fast global changes to datasets. For example, if I decide to change the way I label an I/O I can change it globally and updated all items rather quickly.

The Excel export should definitely include the columns for I/O data.
If the spreadsheet you create for CSV import includes them why not go the other way? Consistency is important.

Attached is an example of how I enter I/O data. However, it doesn't contain the script which compiles data into the importable format.

Jack Frost · 01-13-2008, 08:23 PM

Quote:

This is more of a feature request than a bug. There is currently no function to map what fields export to Excel.

Seth,
This is NOT a feature request. From your reply I think (I hope) you missed my original point. I'm not asking for a way to MAP fields, I'm asking why, when I run the export function which apparently has (as you confirmed) no mapping or options, does the resultant export NOT INCLUDE ALL OF MY DATA ?? (inclusive my I/O tables)

IOW, I ran an export. Not all my data was in the resulting data set. An option/setting/user error was not the reason why.
THAT is a BUG.

If you could offer a workaround and/or timeline till it's fixed that'd be much appreciated.

thx.
J.

Reed Phillips · 01-14-2008, 12:32 PM

It is my understanding that this was by design due to concerns about D-Tools competitors ripping off data that D-Tools had created. You may be able to get access to the data via an Excel report rather than the Export function.

SenoS · 01-14-2008, 02:11 PM

[quote=Reed Phillips;6254]It is my understanding that this was by design quote]
J,

That is my understanding as well, hence the terminology disagreement. We can call this a feature request or we can call it a bug. Either way, the request has been submitted so hopefully this will be a part of a future release.

I cannot comment on a timeline but perhaps a member of our development team may end up commenting on this post.

The only workaround that I know of is edit the data directly in the Access database as mentioned in my previous post. If anyone else has come up with a workaround, please post. I'm sure that it would beneficial to others.

Reed Phillips · 01-14-2008, 05:08 PM

Senos,

I haven't looked, but I would assume this data is available to reports and as a result would be available to Excel reports. If so, that would be the easiest way to access the data in Excel format.

RandyB · 01-14-2008, 07:26 PM

Originally Posted by Jack Frost

I spoke to DT support on this and could not get a conclusive answer. When I use the excel export function in MMPD, the resulting file does not have the I/O's of the products.
The DT Support rep basically told me he did not know of any other way to export the data, and the export function in the MMPD does not seem to have any settings, options or adjustments that I can find. So why is this happening?

This looks like a bug in the export code to me.
Please advise.

ty.
J.

Jack,

Please see my response in this link. I'd like to get more information about what you're doing when you need access to the I/O data.

http://www.d-tools.us/bugs-section/1954-export-csv-not-exporting-all-data.html#poststop

Thanks,

Randy

RandyB · 01-14-2008, 07:28 PM

Originally Posted by Reed Phillips

I would assume this data is available to reports and as a result would be available to Excel reports. If so, that would be the easiest way to access the data in Excel format.

I/O data is not available via reports and therefore not accessible in Excel reports. Besides, these run on projects, not your product database.

Currently, the best way to access this data is to sign a non-disclosure agreement and open the access database directly. This is what most users do and you should be able to get help on the forum for doing this.

Historically, D-Tools has never exported I/O data since it represents a valuable part of our Data Subscription data and we wish to protect that property. However, this assumption is being challenged, so your suggestion is being taken into serious consideration.

We are looking at doing something in an upcoming release to make it easier for you to edit I/O's. However we're not exactly sure yet. Is there anything else you can tell me about why you need to export the I/O data? Is it for editing or reporting purposes? There may be another way we can give you to do what you need to do.

Best regards,

Randy Bownds
Program Manager
D-Tools, Inc

Jack Frost · 01-14-2008, 07:58 PM

Thanks for the reply Reed. Could you elaborate on how you mean? I'm not sure I get the reference to "excel reports" (reporting center?) and how I'd get my I/O's out of there.

Of course the intent would be to import them back in so: would the output spreadsheet match the format expected for import?
thx.

Seth:
Thanks for putting it in as a request.
I don't understand the reasoning (theft by competitors) for such a move. It's not as though the data is so superior as to warrant that level security. More often than not the data is mediocre at best and most always requires "hand massaging" just to be usable. I won't go down the road of how heavily SOLD the data features were/are and how dissapointing the reality of the data really is. I think you know, very well, just what I mean.

Most DT data (including stuff downloaded and particularly from the Data Exchange) doesn't even include I/O's. And when it does it's rarely right and consistency is less than an afterthought. (try using the wirewizard on stock data...)
Most (if not all) products in my DB have had the I/O's done or re-done by me.

Essentially this "by design" choice is locking me out of MY data which I worked HARD to make usable. It is up to ME to determine how I want to use it and downright WRONG for DT to prevent my doing so "by design"!
There's no reason why I should have to jump through hoops w/ Access and signing NDAs for DB access (that could affect my support terms/agreement) just to have access to the data that I BUILT. If you want to lock up the mediocrity you supplied me with that would be arguable. To lock me out of that which I created is cruel and unjust.

And for the record, my intent is to try to figure out a way to import/export at least some amount of data back/forth from SI4 to 5 and vice versa (a feature that should already be IN SI5, considering we're already at service release 3 HINT HINT). The thought of repeatedly converting my SI4 database to 5 (and therefore blowing away anything I've done in SI5 db) is numbing.

Hopefully we'll get these things resolved much sooner rather than later.

And anyone with any thoughts on workarounds please do post them.
All help is appreciated.

J.