Hi Stephen,
Thank you for contacting us. I'm not sure why you feel that mSecure should be exporting empty fields. Can you let me know exactly what you are exporting your information for? I don't understand why mSecure should export information that you are do not use.
If you are using our import/export options to export and import mSecure information, you would likely be much better served using our Backup and Restore functions instead.
I want to share my mSecure data with another application and it cannot natively read your mSecure file format. This is where CSV files come into play as it allows applications to share information with one another when they cannot natively read each others data. While there are various specifications and implementations for the CSV format, there are a few standards that are implemented by virtually everyone. This is that a single record in an application will be represented by a single line in a CSV file when exported, and every line in the CSV file must contain the same number of fields where are separated by a comma, thus the name CSV or Comma Separated Values.
To illustrate this I have created a test file for you. In this file you will find a login listing which consists of urls, usernames, and passwords. Open this file in Microsoft Excel and look closely at cell B5. Did you notice that this cell contains a password and not a username? This is because that row in the CSV file does not contain the same amount of fields separated by a comma as the rest of the file. The application that created this CSV file did not have a value for the username associated with the url "http://www.link4.com" and therefore just skipped over it without exporting anything. This is what mSecure is doing wrong. What it and you should have done is export this field as two commas ",," indicating no value for this field in this record. This is important so that the rest of the fields in the row (or cells in a spreadsheet in our example) line up properly. If an application wants to export as a ".txt" file then they can throw the data in there any way they want. But if you are creating a CSV file you must have the same number of fields for each row or when the data is imported into another application (a major usage for CSV files) the fields will not line up properly and the import will be broken.
Stephen is making a good point - if you export his software license example, delete the original and import back the csv file the columns no longer match.
There are all sorts of reasons for exporting and importing (such as making mass changes) that are not satisfied by backup and restore.
I get Andy's point. However, I don't understand why exporting for another application would matter. Other applications are not going to have our exact setup. Additionally, if you use the fields, the fields will be exported so you can use them on other applications. I'll note this to our developers and make a point about this being needed for using our import/export options when making changes to mSecure data.
This will be my last post on this topic as I have moved my data out of mSecure and into another application. This is for the benefit of those that will follow so lets try this again with a picture. In the image below you will see that I have imported a CSV file into excel and take notice to the items in bold. Notice that cell B5 does not contain a username, but rather a password. The reason is that the application that created the CSV file did not have a value for "username" for the record in line 5. This application (like mSecure) did not export a value for "username" because one had not been entered. This causes a problem because the value for "password" is actually imported into the "username" column. Also notice that the value for "email" has been imported into the "password" field. This could have been prevented if the application would have exported a placeholder in the form of ",," into the CSV file. What this does is we are telling the CSV file "I do not have a value for this field but I am exporting a placeholder into the file so that all the other fields will still line up correctly in the proper position." Now focus your attention on cell C9 and notice that "username" has been imported into the "password" column. Why? Because the application (like mSecure) did not have a value for "password" so it exported nothing. Now when the CSV is imported into any other application the data will not be in the correct fields.
You absolutely must export all fields (even empty ones) into a CSV file so that data remains in the proper place. Many applications will allow you to perform "field mapping" where it will look at the column headers of a CSV file (url, username, password, and email in our example) and allow you to map them to fields in the application. For example, if I wanted to import this CSV file into the fictional application "Wazoo", which contains a field named "link", it would allow me to map the column "url" in our CSV file to the field "link" in the application. This will work perfectly fine as long as data in the CSV file is in the proper columns. If we were to import the CSV file below you see that two records would contain the wrong data.
For your convenience I have attached the CSV file to this post and feel free to open it in excel yourself. Now this is a small example with only 10 records and 1 header row. Imagine if it contained thousands of records that had been improperly exported like mSecure does. Just so you know all applications must follow these export rules to maintain data integrity. This is what allows data to be exchanged between applications using the CSV format. Even if mSecure itself tried to import a badly formatted CSV like this one it too would contain bad data. This is really very basic stuff right here … CSV 101 for beginners. When you want to dump data for any other purpose than data sharing, then use a good 'ole txt file and dump data in any format you want. But when you use a CSV file it is implied that you are exporting in a format that will allow the data to be imported and utilized in any application that supports CSV.
Thank you for the added information and the screenshot. I knew exactly what you were saying from the beginning and can see the benefit of it. Though the issue can also be fixed by having information for all fields, and mSecure 5 for Mac already adds the ,, to empty fields, I have created a bug report for this issue on Windows. In the future our CSV export will create empty columns for empty fields when needed.
This is great news and I am a long-time fan of mSecure, though honestly I prefer earlier versions of the software to the current one. They made better use of screen space whereas the current versions data listing is just huge. Also, you are correct if the user enters data in all fields this will fix the CSV issue, but it may be unrealistic to expect them to do so.
mSecure 6 is still having this issue. I cant export my data properly, the csv doesnt display properly. it just another reason I'm looking to move after many years a loyal customer.
I don't understand what you mean here Stuart. mSecure 6 exports a completely different format of CSV data than in mSecure 3 or mSecure 5. Can you please explain what you mean when you say v6 is still having this issue? What issue exactly are you having? Please provide me a concrete example from a row of data, with all sensitive information redacted of course, and I will try to figure out what's happening.
Also, I'm sure you're not wanting to move away from mSecure because of CSV exporting alone. Is there some other issue I could try to address? When our customers experience issues in the app, we do all we can to fix the problems if they are running into bugs they can help us reproduce. If you have been using the app for some time, it may be a lot simpler to have us look into and fix any problems you might be running into than migrating to a new password manager. I would be happy to help in any way I can.
If I don't know what you are actually experiencing, how in the world do you expect me to help you? When I export my data to a CSV file, it works just as it should. The feature has been tested thoroughly. If there is a bug, and if you found that bug, it would be wonderful for you to help us to see what the problem is. If you don't want to help us understand what you are experiencing, then there will literally be no way for us to help you get your data out, because we are not experiencing what you are experiencing. Make sense?
Also, I'm no quicker to respond to negative comments on the forum or via email. I'm the only one who works in the forum, and I have many duties to perform here at the company, especially at certain times in the development cycle. You can decide on anything you would like to believe. That's your prerogative. But your decision to think a certain way doesn't make your belief true.
In the end, if you would like help, I'm always here to help. If you want your data exported to CSV, I can help you get that done. However, if you are not able to export to a CSV file for whatever reason, and you are not willing to tell me the behavior you're experiencing, then there is literally no way I'm going to be able to help you. The choice is yours on how to proceed.
Stephen
When exporting data to a csv there is a bug when a field is blank in the application. For example, when exporting a software license there is "Group, Type, Name, Notes, Serial, Licensee, Email, Version, OS". If I leave "Email" empty in the application then export to a csv "Version" is exported into the place where "Email" should appear making all the columns off for the rest of that record. If there is an empty field in the application it is being skipped during the export process when it should be exported as a null field ",,".