Database limits & importing 350 song titles

[Daddyg]

Hi,
Just wanting to check before I muck up the works here.  I've split a songbook PDF into 350 individual "pages" that are each their own file.  I've set up an import file to be able to import into an SLM database.  So far, so good.  I've got two questions that I've not been able to find answers to through searching/browsing:

-Is there a limit of how many docs a database can hold, and do you see any issues in importing that many song titles at once?

-Once the "songs" are set up in the database, I have to attach the documents to each song.  I see how you can import multiple documents into SLM, but is there any way to attach like titled documents to same titled songs?

I have 5 databases already that are used all the time, so I don't want to corrupt things with this massive import into a new database.    Any help appreciated.

[arlo]

Just wanting to check before I muck up the works here.  I've split a songbook PDF into 350 individual "pages" that are each their own file.  I've set up an import file to be able to import into an SLM database.  So far, so good.

Do you have one file per song and one song per file? If you have, let's say, a two-page song that is split across two files, that makes things more complicated.

-Is there a limit of how many docs a database can hold, and do you see any issues in importing that many song titles at once?

No, but remember that you can batch-import but can't batch-delete. So it's best to test your import file with a small number of songs before importing 350. Of course if it is a new database, you could just delete the database and start over if needed.

-Once the "songs" are set up in the database, I have to attach the documents to each song.  I see how you can import multiple documents into SLM, but is there any way to attach like titled documents to same titled songs?

When you set up your import file, you can list the file names associated with each song. If the file names match the song names, this will be easier than if they vary. You should also be able to copy and paste a list of filenames from the Mac or Windows desktop into your import file.

I have 5 databases already that are used all the time, so I don't want to corrupt things with this massive import into a new database.

Importing into one database won't affect the data in the others.

[Daddyg]

Thanks, Arlo.  Yes, one file per song and one song per file.

Yes, if something goes wrong with the import, I could just delete the database and start again.

Interesting...so I can list the file names in the import file, along with the song name, which are one in the same, and it will import (create) the song in the db, along with importing the file (with the pdf) into that songs documents?   THAT would be excellent.  I'll look back over the template posted here to see exactly which fields are importing to what. 

I found this little program that adds a "copy filename" command to Explorer.  Breaking apart the large PDF into individual files, it makes it really slick to then assemble the import file.

Is the size of the database only limited to the memory on the iPad?  Having larger databases would seem to be more prone to corruption, especially using import functions, or at least that's my experience with databases.  Which brings me to a question I've been meaning to ask...what are your thoughts on providing additional database features for SLM in the future?   A routine to check the integrity of the DB, possibly a repair function, the ability to merge databases, and interact on a more macro level, i.e. group deletions.   After using SLM for like 4 years or so, I find myself needing more administrative tools frequently.  I'll bet many long time users run into the issue too.    Just curious.

[arlo]

Interesting...so I can list the file names in the import file, along with the song name, which are one in the same,

(Plus the file name)

and it will import (create) the song in the db, along with importing the file (with the pdf) into that songs documents?

This doesn't import the file (meaning copy it into the app), it only sets up a link to the file, and you still need to copy the file into the app.

Is the size of the database only limited to the memory on the iPad?

There is probably a practical limit before that, but I've never seen anyone who ran into problems caused solely by a large database, other than some pages loading more slowly if they contain long lists of items.

what are your thoughts on providing additional database features for SLM in the future?   A routine to check the integrity of the DB, possibly a repair function, the ability to merge databases, and interact on a more macro level, i.e. group deletions.

I haven't seen a need for a "check and repair" function on iOS. Android will occasionally screw up the saving of a database, so it now automatically saves a backup and automatically opens the backup if the primary copy is corrupted. This is less of an issue in BandHelper since all your data is backed up on my server automatically. Merging databases would be very difficult in Set List Maker, but easier in BandHelper, so that's something I would consider adding there, but so far nobody has requested it. BandHelper has a full set of batch update and batch delete functions.

[Daddyg]

Thanks so much for your responses, Arlo.  Think I understand it all.  Still separating the massive PDF file into individuals files (very arduous) but I'm getting closer.

FWIW, whether it's moving multiple files from one db to another, or merging them, consider this a request for this feature in SLM, along with group additions/deletions.  I've considered BandHelper and I really don't need much of its functionality, but I would be willing to pay for these sorts of add ons to SLM.

Thanks again.