Update of D ID exclude service/location: Difference between revisions
Ttenbergen (talk | contribs) mNo edit summary |
Ttenbergen (talk | contribs) Really not something we need to do now that we use PatientFollow and there are much fewer changes to Service_Location |
||
| Line 1: | Line 1: | ||
This page documents our move to a [[D_ID]] that no longer contains the [[Service/Location]]. | This page documents our move to a [[D_ID]] that no longer contains the [[Service/Location]]. | ||
{{LegacyContent | |||
|explanation= The reasons to do this are no longer valid. | |||
|content= | |||
== Background == | == Background == | ||
=== Rationale for doing this === | === Rationale for doing this === | ||
At some point, including the [[Service/Location]] in [[D_ID]] was the biggest cause of [[Orphans in Centralized data.mdb]], and required special processes such as [[Changing D IDs]]. With everyone now entering fewer profiles and fewer [[Service Location]]s due to [[PatientFollow Project]], there should be much fewer problems caused by this, so this change is likely not worth the effort. | |||
==== Rationale for ''not'' doing this ==== | |||
This would be a fairly troublesome change for sending. | |||
Also, if there is an outstanding [[Instructions for requesting a batch of data from DSM | request]], changing the [[Service/Location]] can break the connection to the returned data when it is [[Instructions for importing a batch of DSM Data |imported]]. | Also, if there is an outstanding [[Instructions for requesting a batch of data from DSM | request]], changing the [[Service/Location]] can break the connection to the returned data when it is [[Instructions for importing a batch of DSM Data |imported]]. | ||
=== Considerations that it is possible to do this === | === Considerations that it is possible to do this === | ||
| Line 27: | Line 29: | ||
We will either need to make the change contingent on start_date field or there will be [[Orphans in Centralized data.mdb]] to clean up. | We will either need to make the change contingent on start_date field or there will be [[Orphans in Centralized data.mdb]] to clean up. | ||
Some steps required: | |||
* created Function make_D_ID | * created Function make_D_ID | ||
** '''Problem:''' If I use a function for this, then the way the delete queries work breaks with a non-specific ''#Error'' if a record has been deleted; Possible solutions: | ** '''Problem:''' If I use a function for this, then the way the delete queries work breaks with a non-specific ''#Error'' if a record has been deleted; Possible solutions: | ||
| Line 37: | Line 39: | ||
* I plan to have this function just generate the old style D_ID for now, and integrate it into all the sending spots. Then we can decide the start dttm after which we want to use the new format, and I just set that as a parameter in the function. | * I plan to have this function just generate the old style D_ID for now, and integrate it into all the sending spots. Then we can decide the start dttm after which we want to use the new format, and I just set that as a parameter in the function. | ||
=== Data use - no changes required === | === Data use - no changes required === | ||
| Line 53: | Line 53: | ||
{{Related Articles}} | {{Related Articles}} | ||
}} | |||