[TechDad]

When sharing songs and data by creating an .msf file, I encountered a few minor errors when importing to my other tablet.

Background
I created a custom field named: Page # Sort, used to sort the songs by page number.

• It consisted of a three digit page number + space - space + the song title
  
• i.e.  340 - Take Me Home, Country Roads
  

I created a Source: The Daily Ukulele - Leap Year Edition
I created a Collection: The Daily Ukulele - Leap Year Edition

I'm in the midst of putting the whole book into MobileSheets Pro for convenience.  The ebook doesn't have the functionality of MobileSheets Pro's database.

To create the .msf file, I selected all the pages for the source, tapped on Share, tapped on Share as .msf, and created a file that I uploaded to my Google Drive folder.

In my other tablet, I tapped on import, Google Drive, selected the file, and proceeded to import the files and data.

Here are the errors I encountered:

• Custom Field (Page # Sort) - entries that had a comma in this field were split into two listings, right at the comma
  
• The first part of the custom field entry with the page number was created, and a second entry was created with the text after the comma.  The comma itself was not included in either of them.
  
• In the example I used above, it created two entries: 340 - Take Me Home & Country Roads.
  
• The source entries fields were filled in correctly, but the import did not create the specific source category.  I had to create it manually.
  
• The collection entries were filled in correctly, but the import did not create the specific collection category.  I had to create it manually.
  
• The custom field name (Page # Sort) was not imported.  I had to create it manually.
  

Thanks for your help on this.  I want to get it working properly so I don't have to manually fix the entries (mainly the comma issue).

Enjoy the day,

Charles

[Zubersoft]

I'll look into it as soon as I can. If I can't reproduce the issue, I may need to get the .msf file from you for testing.

Thanks,
Mike

[itsme]

"... putting the whole book into MobileSheets Pro for convenience ..."
Did you take a look at MSPs "CSV import" feature?

[TechDad]

"... putting the whole book into MobileSheets Pro for convenience ..."
Did you take a look at MSPs "CSV import" feature?

I'm using MobileSheetsPro Companion to put these two books on my tablet.  I don't see that it imports csv files.  Also, all of my songs are separate pdf's, so I'm not sure csv importing would work.

But I will look further into it and see if it will save any time.

Thanks for the suggestion,

Charles

[itsme]

For PDFs containing only one song CSV import doesn't make sense.

[BRX]

It might, if Mike considers to change the csv import with one more field. I had suggested it quite a while ago but didn't get a response from Mike or an entry in the to-do-list, so I don't know if Mike's is aware of it.

So, Mike, can you add a field for the source PDF so MSP can read that from the csv file (with a general filename like for instance import.csv) and doesn't need the same names of csv and PDF? I imagine that's not too hard to implement.

I would ease the import of PDFs with only one song. Also it allows the import from different PDFs in one csv which would be great for selective imports, especially for corrections and other changes which could be collected in that one import.csv.

[Zubersoft]

So basically add support for a new column called something like "file", where you can list the path to the file you want to use for each entry? I don't think that would be too difficult to add. If a file isn't listed for an entry, I would need to figure out the right way to handle that though. I'd probably have to ignore it.

One problem that I can see right now is that my current logic looks for a matching PDF when a CSV file is selected. In order to support this new option, I would have to figure out first if the file column is present in the CSV file. If it is, I wouldn't require a matching PDF anymore, but I would probably have to ignore any entry that doesn't point to a valid file. If the column isn't present, then I would have to fall back to the current implementation where a matching PDF has to be present. Thoughts?

Mike

[BRX]

Nothing to add from ne. That's how I thought would be the best (to keep the old filename way as a fall back).

One related thought though. It would be good if one could use something like #, all or whatever (not 0 though) in the pages column to indicate that all pages should be imported without having to specify or even know the page count. If it's possible, that is.