Here is the problem to submit to you:
I want to integrate nearly a thousand sources to my RootsMagic file. A part comes from books, the biggest part comes from public archives.
This inventory on excel is presented in the following way:
Deposit : ex : Bibliothèque Nationale de France
Series :. Ex. B. (Courts and jurisdictions)
Ref :. Ex B. 440 f°13
Analysis : description of the manuscript or document
Date : date of the document
RMid : the RM number of the person most concerned by the source.
Is there a way to enter all this information without having to re-enter it manually data, which would require a lot of work?
Nope, not native to the program itself. One might be able to export an Excel file to a .CSV file and import using SQL via fancy machinations with SQLite directly, but that requires deeper database understanding.
Another approach a cousin of mine once took was to convert such data to GEDCOM and import the GEDCOM. I think a CSV file was used as an intermediary. I don’t remember if she converted the CSV to GEDCOM using a powerful text editor or if she did it by writing a little computer program.
Thank’s for your advices [kbens0n], [thejerrybryan] and [hkcraswell] .
I have started to look at the problem. It seems to be complicated. As I understand it doesn’t seem possible to insert sources in a GEDCOM file that are independent of an individual. If I associate the source with the individual, I fear either deleting all the other data associated with the individual or having the same individual twice.
The only solution that seems possible to me would be to import directly data into the SQL tables of the source parameter with the title in the form “RMid, Repository name, SourceId, label” to be able to easily find it in the list of sources. Would the RM developers be able to propose a simple solution?
Other ideas?
I am not a developer but we could dream of a simple and elegant data import function based on an export request created by the user in RM because in this case the fields in question and the structure of the database are known to RM to generate the result. This would allow the user to know what his import request could give and would avoid the user having to understand the programming.
To sum up, wouldn’t it be possible for RM to create the reverse function of the export which would be the import request. Probably, in this case provide other information as the name of the import file and some other parameters will probably be provided.
I specify that these questions of importation are the weak link of the genealogy software for the inventories of sources or genealogical statements whose data entry is largely more efficient on a spreadsheet. It’s up to RM to innovate to have a competitive advantage.
Looking forward to reading you.
You would need to associate all the sources with a dummy person in the GEDCOM you were creating to get them imported. After they were imported, you would need to associate them with the correct people and facts and citations and that sort of thing from within RM. It’s hard to see how you could ever automate this latter part of the job for thousands of sources. Using SQLite instead of GEDCOM would not solve that part of the problem.
RM does have a GEDCOM import function. That’s the reason that the users sometimes will convert Excel files or CSV files or the like to GEDCOM format. But even if RM someday had a direct Excel or CSV import function, that wouldn’t really solve all the problem for importing sources. The sources would still have to be cited to people and facts and the like.
Given that your table has the RMid or RIN for the people in the database to which you wish to add the sources, I daresay that it could be feasible to generate the Master Sources and Citations linked to the Person in the database using SQLite. I very much doubt that they could be linked to other facts or events for which they may provide evidence unless the necessary data for that is also in the spreadsheet (fact type, date, place, description) and even more complicated and doubtful if the fact already exists in the database.