Discussion :

[lparodi]

Comment puis je faire ça ? De quel code s'agit il ? (Je n'ai pas encore migré, puisque le preupgrade n'est pas clean).

Il s'agit du code source des procédures stockées, triggers, vues ou autres, stocké à l'extérieur de la base de données. Dans mon environnement professionnel, tout est enregistré sous subversion et on est capable de ressortir à tout moment le code d'une procédure stockée, avec ses révisions successives.
Si vous n'avez pas le code, il faudra le reconstruire à la main, en utilisant sp_helptext ou encore mieux, sp_showtext.
Il ne faut pas perdre de vue que le dataserver essaiera de reconstruire tous ces seuls ces objets à partir de syscomments, lors du 1er appel après l'upgrade. Il n'y a donc pas vraiment le choix, il faut passer par cette phase de reconstruction, si nécessaire.

Vous pensez que je dois migrer quand même, puis exécuter dbcc upgrade_object sur les defaults en 15 (le script preupgrade se conclut par Upgrade eligibility test succeeded, malgré ces 6 text errors) ?

Idéalement, il faut construire l'environnement 15.0 à côté et tester l'upgrade. Là, vous avez tout loisir de tourner le dbcc upgrade_object pour identifier les objets.
Si l'upgrade in place est la seule solution :
- bien noter le nom des objets (le preupugrade est notre ami)
- préparer le DDL de ces objets
- upgrade
- compiler le DDL, avant de redémarrer les applications
A noter, le preupgrade retourne des informations et des erreurs. Le code source manquant est un warning seulement, donc cela n'empêchera pas l'upgrade de se dérouler.

D'autre part j'ai essayé de créer un default pour tester (avant d'essayer de dropper et recréer les fautifs).

Ce qui n'est pas du tout ce que je veux ...

Any suggestion ?

Il y a deux manières de créer des default :
- lors de la création de la table :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
create table archive (
id int,
date datetime default getdate() )

- ou manuellement à l'aide de create default

En effet, le contenu de syscomments est différent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
1> sp_showtext archive_date_1791345446
2> go
DEFAULT  getdate()
(return status = 0)

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
1> create default Dtest as "2 null"
2> go
1> sp_showtext Dtest
2> go
create default Dtest as "2 null"
(return status = 0)

[Laurielee]

En effet, le contenu de syscomments est différent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
1> sp_showtext archive_date_1791345446
2> go
DEFAULT  getdate()
(return status = 0)

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
1> create default Dtest as "2 null"
2> go
1> sp_showtext Dtest
2> go
create default Dtest as "2 null"
(return status = 0)

Oui, c'est bien ce que j'ai vu. Mais le comportement du DEFAULT est il différent par la suite ?

[lparodi]

Oui, c'est bien ce que j'ai vu. Mais le comportement du DEFAULT est il différent par la suite ?

non.
L'avantage de celui créé manuellement est qu'il est réutilisable

[Laurielee]

Merci beaucoup lparodi, j'essaie, point peur !

Et je vous dis quoi ....

[mpeppler]

Par contre il faut "binder" un default indépendant via sp_bindefault pour qu'ASE sache où il doit l'appliquer.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
sp_bindefault 'nom_du_default', 'ma_table.la_colonne'

Michael

[Laurielee]

Décidément je n'ai pas de chance ....

J'ai essayé de dropper les DEFAULT .... et en fait il s'avère que ce sont des contraintes (comme tu avais dit au début, Michael).

1> drop default PORT_PORT_A_728389664
2> go
Msg 3710, Level 16, State 1:
Server 'ORION', Line 1:
Cannot use DROP with 'PORT_PORT_A_728389664' because 'PORT_PORT_A_728389664' is
a constraint. Use ALTER TABLE.

J'ai donc affiché les contraintes sur la table PORT (bien essayé, c'est bien la bonne):

1> sp_helpconstraint PORT
2> go
name
definition
created
------------------------------
------------------------------------------------------------
-------------------
PORT_PORT_T_760389778
DEFAULT 1
Jul 8 2003 9:01AM

PORT_PORT_A_728389664
DEFAULT 2 nul
Jul 8 2003 9:01AM

PORT_PORT_P_744389721
DEFAULT 2 nul
Jul 8 2003 9:01AM

PK_PORT
PRIMARY KEY INDEX ( PORT_ID) : CLUSTERED
Aug 19 2004 12:28PM

(4 rows affected)
(return status = 0)

Je retrouve bien mes deux coupables.

Par contre pourquoi la première et la dernière passent elles sans problème, et pourquoi quand je vais voir par Sybase Central (sur la cellule de test ici, je n'y ai pas accès chez mon client) je ne vois que la dernière ?

Et les 3 premières ne semblent pas liées à des colonnes de la table.

La question suivante est comment fait on pour recréer de telles contraintes à l'identique si on doit les dropper et les recréer ?

Je suis désolée d'être si ignorante ...

Edit : je viens de faire un sp_helpconstraint sur les 5 autres tables pour les 5 autres objets, et j'ai l'impression que c'est la mention du "nul" qui pose problème ?

[mpeppler]

En principe on peu dropper une contrainte avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
alter table drop constraint ....

Dans le cas d'un "default", on doit pouvoir le dropper via

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
alter table replace <nom_colonne> default NULL

et le recréer comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
alter table replace <nom_colonne> default <expression>

A la réflection je pense que l'on doit pouvoir directement faire la deuxième version, qui doit remplacer le default avec la mauvaise syntaxe.

Evidemment il faut savoir quel default il faut mettre - et comme "2 nul" n'a aucun sense comme default il faut probablement faire quelques recherches du côté du code source...

Michael

[Laurielee]

Le problème c'est que je ne sais pas à quelle colonne correspond la contrainte.

PK_PORT est liée à PORT_ID, mais les autres ?

[mpeppler]

En principe:

sp_help <tablename> va donner le nom du default associé à une table.

Si ce n'est pas le cas alors il pourrait y avoir un problème plus sérieux...

Michael

[Laurielee]

sp_help <tablename> m'a donné le renseignement !

La valeur 'nul' n'est pas acceptable pour ce champ.

J'ai fait un
ALTER TABLE <table_name> REPLACE <nom_colonne> DEFAULT <expression>
en ne mettant que le chiffre dans <expression>.

Et c'est bon, ça ne sort plus en erreur !!!

Merci à Michael et à tous de votre aide précieuse.
Espérons que mon upgrade va se dérouler sans plus de soucis, quand j'aurai modifié les 6 autres contraintes....

Bon week end (le mien sera plus serein )

[Laurielee]

Ca y est, mon upgrade est fait et tout marche bien !!!
Pour revenir sur ma question initiale, c'est en effet apparemment un bug de la 15.0.2, parce que j'ai pu setter le default data cache à 1600M sans problème sur la 15.0.3.

Merci encore à tous pour l'aide. Je pense qu'on peut clore le sujet.