[Arches] Re: BUG: Concept Schemes won't delete - and a workaround

[Vincent Meijer]

Came across the same issue and this comment was very helpful, thanks. :)

On Tuesday, 19 January 2016 13:52:23 UTC-5, Bryan Alvey wrote:
>
> Hi guys,
>
> I have arches running on an 8Mb Windows server r2 platform on google 
> cloud. 
>
> Here is another bug I came across when testing the RDM, noted as an issue 
> in github (https://github.com/archesproject/hip/issues/3).
>
> If you inadvertently create a concept scheme in error, then you won't be 
> able to delete it until you populate it with some data.  Empty schemes 
> won't get deleted, but when you add some data to them, they will delete! (I 
> panicked for a good hour...)
>
>
>

-- 
-- To post, send email to archesproject@googlegroups.com. To unsubscribe, send 
email to archesproject+unsubscr...@googlegroups.com. For more information, 
visit https://groups.google.com/d/forum/archesproject?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to archesproject+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Arches] Re: Creating .Arches files

[Vincent Meijer]

Awesome, thank you very much. Especially a big +1 for the 'UNION ALL' 
directive! :)


On Wednesday, 4 January 2017 16:54:47 UTC-5, Adam Cox wrote:
>
> This is what Lucy was so graciously referring to: 
> https://arches-hip.readthedocs.io/en/latest/extra/#from-ms-excel-workbook
>  :)
>
> You are most of the way there, but pay close attention to the GROUPID. 
> Technically what you have written will work fine, but if you try to add two 
> attributes to the same resource that should be grouped (like name and name 
> type, as is illustrated in the documentation above) you will need to set 
> the groupids for those resources to match.
>
> As for relationships, that will be tricky. In the past, I've written small 
> python scripts to read from tables and create the .relations file. 
> Generally these scripts are very specific though, so not really applicable 
> outside of their initial use, and I haven't used SQL for that at all. Note 
> that you will need to use the RESOURCEIDs from your .arches file in the 
> .relations file.
>
> Perhaps others have some good SQL samples for achieving this task.
>
> Good luck! Migrating data is often a very complex task, so I'm interested 
> to hear how it goes for you.
>
> On Wed, Jan 4, 2017 at 1:46 PM, Vincent Meijer  > wrote:
>
>> Where can I find Adam Cox's excellent guide to creating a .Arches file? :)
>>
>> I am importing an old database that is a huge mess, and it seems I will 
>> need to prepare a .arches file by querying every column of every table into 
>> a .arches format. 
>> E.g. this query:
>>
>> select CONCAT('HERITAGE_RESOURCE_', SpecimenID) as "RESOURCEID", 
>> 'HERITAGE_RESOURCE.E18' as "RESOURSETYPE", 
>> 'NAME.E41' as "ATTRIBUTENAME", 
>> CommonName as "ATTRIBUTEVALUE", 
>> 'NAME.E41' as "GROUPID"
>> from dbo.Specimens;
>>
>> will result in: 
>>
>> RESOURCEID   RESOURCETYPE ATTRIBUTENAMEATTRIBUTEVALUE  GROUPID
>> HERITAGE_RESOURCE_4  HERITAGE_RESOURCE.E18NAME.E41Hot Springs 
>> NAME.E41
>> HERITAGE_RESOURCE_5   HERITAGE_RESOURCE.E18 NAME.E41 Sapsuk NAME.E41
>> HERITAGE_RESOURCE_6   HERITAGE_RESOURCE.E18 NAME.E41 Sapsuk NAME.E41
>> HERITAGE_RESOURCE_7   HERITAGE_RESOURCE.E18 NAME.E41Adamagan NAME.E41
>>
>>
>>
>> And then of course there are the relations...
>>
>> Any advise/tactics/example sql queries are very welcome! :D
>>
>>
>>
>> On Wednesday, 17 February 2016 12:46:48 UTC-5, Adam Cox wrote:
>>>
>>> Hi Lucy, I have come to a similar conclusion in the past.  It's been 
>>> beneficial to batch import a single .arches file with a good deal of 
>>> information in it, but with no attempt to get absolutely everything.  
>>> Programming a way to convert some of the extra random pieces to .arches 
>>> seemed too costly (time-costly) compared to the relative ease of entering 
>>> that information through the arches interface.  However, populating the 
>>> entire database with a core of base data that could be added to later is 
>>> extremely valuable.
>>>
>>> Also, heads-up!  In v4 it looks like 
>>>  the 
>>> .arches format will give way to a more straightforward import approach.  
>>> That won't be relevant to you for a while, but just something to keep in 
>>> mind before you spend extra time building processes for .arches that you 
>>> expect to use for years...
>>>
>>> Adam
>>>
>>> On Wed, Feb 17, 2016 at 4:07 AM, Lucinda Fletcher-Jones <
>>> luci...@gmail.com> wrote:
>>>
 Hi Adam,

 Your help is always appreciated and I really like the MS Excel query 
 method of converting the excel file into an .arches file but that 
 perennial 
 problem, diacritics, is rearing its ugly head again. The MS query cannot 
 import the diacritics from the Excel file (I have tried many times using 2 
 different versions of Excel) and so adding those extra rows as you suggest 
 below would be necessary for every resource as we have the Arabic name and 
 an English name with diacritics for each. It probably wouldn't take that 
 long but allows for human error to creep in...

 I also looked into using Open Office. By googling, I found a method by 
 which I could use OO Base, import the Excel file and create a query from 
 that. But, the modified query is not working at present. I have some 
 syntax 
 problems but I also believe that this method can only handle very simple 
 queries.
 As for the macros, I don't know python and my Javascript is rusty, so I 
 might leave that to a new programmer coming on board soon. 
 I am rapidly coming to the conclusion that a combination of batch input 
 through .arches files and user input might be best for our project!




 On Monday, February 15, 2016 at 7:42:42 PM UTC+2, Adam Cox wrote:
>
> Hi Lucy, personally I'd recommend modifying (a copy of!) the excel 
> file, because then you can continually recreate the