Este artículo explica cómo mantener una variable numérica subyacente (para los cálculos) mientras se fuerza su visualización en formato de fecha.
El Problema: Almacenamiento vs Visualización
Desea crear una tabla donde la fecha se almacene como un número (para permitir futuras ordenaciones y cálculos) pero se muestre como una fecha legible (16JUL2023).
/* 1. Création via FedSQL */
proc fedsql;
create table work.ma_table as
select datepart(timestamp_col) as ma_date
from source;
quit;
/* 2. Modification des métadonnées via PROC DATASETS */
proc datasets lib=work nolist;
modify ma_table;
format ma_date date9.;
quit;
run;
1
/* 1. Création via FedSQL */
2
PROC FEDSQL;
3
create TABLE work.ma_table as
4
select datepart(timestamp_col) as ma_date
5
from SOURCE;
6
QUIT;
7
8
/* 2. Modification des métadonnées via PROC DATASETS */
Es tentador resolver el problema directamente en SQL convirtiendo los datos:
/* À ÉVITER si vous voulez garder du numérique */
SELECT PUT(ma_date, date9.) as ma_date_str ...
1
/* À ÉVITER si vous voulez garder du numérique */
2
SELECT PUT(ma_date, date9.) as ma_date_str ...
¿Por qué es peligroso? La función PUT transforma su fecha en una cadena de caracteres (VARCHAR).
Pierde la capacidad de ordenar cronológicamente (la ordenación se volverá alfabética: "01FEB..." aparecerá antes de "01JAN...").
Pierde la capacidad de realizar cálculos de fechas (añadir días, calcular diferencias).
El caso particular de las funciones implícitas
Tenga en cuenta que en ciertos contextos, FedSQL es "inteligente". Si utiliza una función que devuelve explícitamente un tipo de fecha (como DATEPART en una marca de tiempo), FedSQL a veces puede asignar automáticamente un formato predeterminado a la columna resultante. Sin embargo, para un control preciso (por ejemplo, preferir DDMMYY10. a DATE9.), los métodos de post-procesamiento (CASUTIL o DATASETS) siguen siendo las únicas garantías fiables.
Función PUT() en el SELECT (se convierte en VARCHAR)
Important Disclaimer
The codes and examples provided on WeAreCAS.eu are for educational purposes. It is imperative not to blindly copy-paste them into your production environments. The best approach is to understand the logic before applying it. We strongly recommend testing these scripts in a test environment (Sandbox/Dev). WeAreCAS accepts no responsibility for any impact or data loss on your systems.
SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration. WeAreCAS is an independent community site and is not affiliated with SAS Institute Inc.
This site uses technical and analytical cookies to improve your experience.
Read more.