trouble with aliases and SAS

[dckc]

@njgraham and/or @mprittie to elaborate and/or report upstream

[njgraham]

@dckc, as I recall we (KUMC) didn't have the same table names as what the SAS script referenced. So, I tried to use Oracle aliases but doing caused a SAS script to fail (I don't recall the error message/code). Perhaps @mprittie recalls more.

Changing our (KUMC) table names to match what's in the SAS script (and matching the PCORNet CDM specification) rather than using aliases seems like the right thing to do anyway. So, perhaps we shouldn't worry about the alias problem.

I wonder if this is the same issue you referenced in #28 with regard to syncing with SCILHS i2p code since I think this one is about SAS - I presume aliases would work with the loader .SQL script (though, I'm not sure). Perhaps I'm confusing issues.

With regard to syncing with SCILHS i2p-transform code, in abdb287, I changed the table names in the loader script to match what the PCORNet CDM specification calls them. Asking SCILHS to change their fork of the loader script to remove the pmn seems it's the right thing to do - in my mind at least - since the CDM specification doesn't have the prefix.

[mprittie]

I agree with @njgraham's appraisal of the issue, and that the final transformed table names should be those specified by the PCORNet CDM spec.

[dckc]

I'm interested to see the argument that convinces upstream to change their table names.

If we were starting from scratch, consistency between the CDM spec and SCILHS/i2p-transform would be pretty easy. But by now, we're one of perhaps a dozen downstream sites. I don't see an argument that makes it cost-effective for SCILHS to deploy such a change.

But this isn't assigned to me, so I won't stand in the way if you manage to convince them.

[mprittie]

We might suggest it to them, but I'm not really advocating trying to get SCILHS to change their table names. I don't think we'll ever be using an unmodified version of the SCILHS i2p-transform. If we decide to integrate the current SCILHS version of the i2p-transform with with our version (which I'm still not convinced is worth the effort), then I assume we will continue to have a significant amount of site specific variation to maintain.

[dckc]

I suppose #28 is the more relevant issue for upstream sync and table naming.

Let's leave this issue's scope to figuring out what's up with SAS and aliases.