<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic PROC METALIB considers formats in different cases to be different in SAS Data Management</title>
    <link>https://communities.sas.com/t5/SAS-Data-Management/PROC-METALIB-considers-formats-in-different-cases-to-be/m-p/875739#M20731</link>
    <description>&lt;TABLE width="758"&gt;
&lt;TBODY&gt;
&lt;TR&gt;
&lt;TD width="758"&gt;Dear all,&lt;BR /&gt;I have recently come across a very surprising behaviour of PROC METALIB: if the format (same format name, same catalog) indicated at the metadata server level uses letter cases(s) different from the letter case(s) used in the descriptor portion of a dataset, PROC METALIB considers these formats as different. &lt;BR /&gt;So if we have, say, the format at the metadata server level written as $ASquared. and the format stored in the descriptor portion of the dataset (to which the metadata object is pointing) written as $ASQUARED. PROC METALIB (noexec; report;) considers the formats are different. &lt;BR /&gt;This is a problem because we are currently using PROC METALIB to identify any discrepancies between the (metadata server) metadata and the descriptor portion of datasets, and this is obviously giving us a (currently unknown) number of false positives (I haven't checked the informats yet, but I assume the same problem wil arise). And it is surprising because SAS does not allow the same format (even with different letter case(s)) to be present in the same catalog (this is SAS on Windows).&lt;BR /&gt;Is this something one of you has already noticed? Is there a fix?&lt;BR /&gt;Many TIA&lt;BR /&gt;Cheers&lt;BR /&gt;Anne.&lt;/TD&gt;
&lt;/TR&gt;
&lt;/TBODY&gt;
&lt;/TABLE&gt;</description>
    <pubDate>Mon, 15 May 2023 06:27:47 GMT</pubDate>
    <dc:creator>Anne_A</dc:creator>
    <dc:date>2023-05-15T06:27:47Z</dc:date>
    <item>
      <title>PROC METALIB considers formats in different cases to be different</title>
      <link>https://communities.sas.com/t5/SAS-Data-Management/PROC-METALIB-considers-formats-in-different-cases-to-be/m-p/875739#M20731</link>
      <description>&lt;TABLE width="758"&gt;
&lt;TBODY&gt;
&lt;TR&gt;
&lt;TD width="758"&gt;Dear all,&lt;BR /&gt;I have recently come across a very surprising behaviour of PROC METALIB: if the format (same format name, same catalog) indicated at the metadata server level uses letter cases(s) different from the letter case(s) used in the descriptor portion of a dataset, PROC METALIB considers these formats as different. &lt;BR /&gt;So if we have, say, the format at the metadata server level written as $ASquared. and the format stored in the descriptor portion of the dataset (to which the metadata object is pointing) written as $ASQUARED. PROC METALIB (noexec; report;) considers the formats are different. &lt;BR /&gt;This is a problem because we are currently using PROC METALIB to identify any discrepancies between the (metadata server) metadata and the descriptor portion of datasets, and this is obviously giving us a (currently unknown) number of false positives (I haven't checked the informats yet, but I assume the same problem wil arise). And it is surprising because SAS does not allow the same format (even with different letter case(s)) to be present in the same catalog (this is SAS on Windows).&lt;BR /&gt;Is this something one of you has already noticed? Is there a fix?&lt;BR /&gt;Many TIA&lt;BR /&gt;Cheers&lt;BR /&gt;Anne.&lt;/TD&gt;
&lt;/TR&gt;
&lt;/TBODY&gt;
&lt;/TABLE&gt;</description>
      <pubDate>Mon, 15 May 2023 06:27:47 GMT</pubDate>
      <guid>https://communities.sas.com/t5/SAS-Data-Management/PROC-METALIB-considers-formats-in-different-cases-to-be/m-p/875739#M20731</guid>
      <dc:creator>Anne_A</dc:creator>
      <dc:date>2023-05-15T06:27:47Z</dc:date>
    </item>
    <item>
      <title>Re: PROC METALIB considers formats in different cases to be different</title>
      <link>https://communities.sas.com/t5/SAS-Data-Management/PROC-METALIB-considers-formats-in-different-cases-to-be/m-p/875762#M20732</link>
      <description>&lt;P&gt;Hi Anne,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Probably the most expedient fix would simply be to make the metada match (case-wise).&amp;nbsp; For that, you could consider updating the physical metadata using these two macros (one to get the formats, the other to apply them (after an uppercase):&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;&lt;A href="https://core.sasjs.io/mp__getformats_8sas.html" target="_blank"&gt;https://core.sasjs.io/mp__getformats_8sas.html&lt;/A&gt;&lt;/LI&gt;
&lt;LI&gt;&lt;A href="https://core.sasjs.io/mp__applyformats_8sas.html" target="_blank"&gt;https://core.sasjs.io/mp__applyformats_8sas.html&lt;/A&gt;&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;/Allan&lt;/P&gt;</description>
      <pubDate>Mon, 15 May 2023 08:51:47 GMT</pubDate>
      <guid>https://communities.sas.com/t5/SAS-Data-Management/PROC-METALIB-considers-formats-in-different-cases-to-be/m-p/875762#M20732</guid>
      <dc:creator>AllanBowe</dc:creator>
      <dc:date>2023-05-15T08:51:47Z</dc:date>
    </item>
  </channel>
</rss>

