Travailler avec PostgreSQL dans un environnement SAS Viya, c'est un peu comme faire cohabiter deux maniaques du rangement qui n'ont pas les mêmes règles. PostgreSQL est intransigeant sur la casse (minuscules/majuscules), tandis que SAS veut tout standardiser.
Si vous obtenez une erreur 'Table not found', ne cherchez pas un problème réseau. Dans 90% des cas, c'est un conflit de guillemets. Mon conseil ? Soyez explicites. Définissez vos schémas dans la connexion (CASLIB) et protégez vos noms de tables avec des guillemets doubles. C'est verbeux au début, mais c'est la seule façon de garantir des pipelines de données robustes et maintenables.
Si l'abstraction du niveau database.schema via la CASLIB est la règle générale dans Viya™, PostgreSQL ajoute une couche de complexité supplémentaire : il est extrêmement pointilleux sur la casse (Case Sensitivity).
C'est là que la majorité des développeurs SAS© perdent leurs cheveux. Voici pourquoi ça coince et comment le résoudre.
SAS© et PostgreSQL ne parlent pas la même langue par défaut :
SAS© (par défaut) : "Je mets tout en MAJUSCULES si on ne me dit rien."
PostgreSQL (par défaut) : "Je mets tout en minuscules si on ne me dit rien."
Le scénario catastrophe :
Vous avez une table Postgres nommée ventes_2024 dans le schéma public.
Vous lancez :
| 1 | select * from PG_LIB.ventes_2024 |
Pour réussir une requête fedSql.execDirect sur PostgreSQL, vous devez être explicite à deux niveaux :
Structurel : Mapper Database + Schema dans la CASLIB.
Syntaxique : Utiliser des guillemets doubles "" pour protéger les noms de tables/colonnes Postgres.
Voici le "Template Parfait" pour PostgreSQL :
| 1 | PROC CAS; |
| 2 | /* ÉTAPE 1 : La définition précise de la CASLIB |
| 3 | C'est ici qu'on gère le "Database.Schema" */ |
| 4 | TABLE.addCaslib / |
| 5 | name="MY_PG_CONN" |
| 6 | dataSource={ |
| 7 | srcType="postgres", |
| 8 | server="pg-server", |
| 9 | /* PostgreSQL exige souvent de préciser la base ET le schéma */ |
| 10 | database="MaBaseCommerciale", |
| 11 | schema="public" |
| 12 | }; |
| 13 | |
| 14 | /* ÉTAPE 2 : La requête blindée |
| 15 | Notez l'usage des QUOTES SIMPLES à l'extérieur |
| 16 | et des QUOTES DOUBLES à l'intérieur */ |
| 17 | fedSql.execDirect / |
| 18 | query='select |
| 19 | "id_client", |
| 20 | "date_vente" |
| 21 | from MY_PG_CONN."MaTableVentes" |
| 22 | where "montant" > 1000'; |
| 23 | QUIT; |
Sur SQL Server ou Oracle, on s'en sort souvent sans guillemets car ils sont moins sensibles à la casse par défaut (ou configurés pour ignorer la casse). Mais PostgreSQL est strict.
Si ça ne marche pas, c'est probablement la casse. Mettez des guillemets doubles autour du nom de la table, et englobez toute votre requête query dans des guillemets simples.
’est l'une des frustrations les plus tenaces quand on vient du monde SAS© traditionnel. Vous essayez de charger des données contenant de longs textes (commentaires clients, descriptions de produits, logs JSON) et vous constatez que tout est tronqué à 32 767 caractères.
C'est un réflexe conditionné : dans le moteur SAS© 9 (Compute Server), le type standard CHAR est de longueur fixe et limité à cette taille. Pendant des années, nous avons dû contourner ce problème en découpant les chaînes en plusieurs morceaux.
Bonne nouvelle : Dans CAS, cette limite n'existe plus (ou presque).
Le serveur CAS introduit un vrai type VARCHAR (Variable Character), similaire à celui des bases de données modernes.
SAS© 9 CHAR (Fixe) : Limite ~32 Ko. Si vous stockez "Oui", il utilise quand même tout l'espace défini.
CAS VARCHAR (Variable) : Limite théorique ~2 Go par cellule ! Il n'utilise que l'espace nécessaire.
Si vos données sont tronquées dans CAS, c'est généralement parce que, par habitude ou par défaut, la colonne a été définie comme un vieux CHAR fixe.
CASTPour forcer CAS à utiliser sa capacité de stockage "longue", vous devez définir explicitement la colonne cible en VARCHAR lors de vos transformations SQL.
Vous pouvez spécifier une taille précise (ex: 100 000) ou utiliser VARCHAR(*) pour demander à CAS d'allouer dynamiquement le maximum nécessaire.
Voici comment transformer une colonne de texte limitée en un champ "grand format" via fedSql.execDirect :
| 1 | PROC CAS; |
| 2 | /* On suppose que l'on a une table source 'MES_DONNEES_SOURCE' |
| 3 | avec une colonne 'commentaire_client' qui risque d'être longue */ |
| 4 | |
| 5 | fedSql.execDirect / |
| 6 | query='create table CASUSER.RESULTAT_TEXTE_LONG {options replace=true} as |
| 7 | select |
| 8 | id_client, |
| 9 | date_reclamation, |
| 10 | |
| 11 | /* On force la conversion (CAST) vers un VARCHAR très grand */ |
| 12 | CAST(commentaire_client AS VARCHAR(100000)) as commentaire_complet, |
| 13 | |
| 14 | from CASUSER.MES_DONNEES_SOURCE'; |
| 15 | QUIT; |
Un autre détail spécifique à PostgreSQL : les IDs sont souvent des BIGINT (Entiers 64 bits).
SAS© Viya™ gère les nombres principalement en DOUBLE (Flottants).
Lors d'un execDirect, la conversion est généralement automatique. Mais si vous faites des jointures entre une table chargée en mémoire (CAS table) et une table PostgreSQL distante :
Assurez-vous que les clés de jointure sont de types compatibles.
Parfois, il faut caster explicitement côté SQL : CAST("mon_id" AS DOUBLE PRECISION).
Passer de l'environnement SAS© 9 classique à SAS© Viya™ demande plus qu'une simple migration de code ; cela exige un changement de mentalité.
Comme nous l'avons vu, les blocages les plus fréquents ne viennent pas de la complexité des algorithmes, mais de la "grammaire" de la connexion aux données. En acceptant de perdre le contrôle direct sur la hiérarchie database.schema au profit de l'abstraction des CASLIBs, et en maîtrisant la rigueur syntaxique imposée par PostgreSQL (notamment cette fameuse gestion des guillemets), vous débloquez la véritable puissance de la plateforme.
Ne cherchez pas à tordre SAS© Viya™ pour qu'il se comporte comme du SAS© v9. Embrassez sa logique :
Définissez vos connexions proprement (Mapping).
Soyez explicite sur les types et la casse (Rigueur).
Laissez le moteur MPP gérer le volume (Performance).
Une fois ces ajustements techniques maîtrisés, la frustration syntaxique laisse place à la satisfaction de voir des traitements de plusieurs millions de lignes s'exécuter en quelques secondes.
Les codes et exemples fournis sur WeAreCAS.eu sont à but pédagogique. Il est impératif de ne pas les copier-coller aveuglément sur vos environnements de production. La meilleure approche consiste à comprendre la logique avant de l'appliquer. Nous vous recommandons vivement de tester ces scripts dans un environnement de test (Sandbox/Dev). WeAreCAS décline toute responsabilité quant aux éventuels impacts ou pertes de données sur vos systèmes.