Foxpro et sql server

BOUALLEG Messages postés 3 Date d'inscription jeudi 31 mai 2007 Statut Membre Dernière intervention 27 mai 2009 - 26 mai 2009 à 17:44
michelatoutfox Messages postés 828 Date d'inscription mardi 5 octobre 2004 Statut Membre Dernière intervention 7 mai 2013 - 22 oct. 2012 à 16:00
j'ai réalisé une application de gestion de la caisse d'un magasin, j'ai utilisé:
 foxpro comme lgge de prommation et sql server comme gestionnaire de base de données,
j'utilise des champs de type date dans ma base de données ( type : datetime et smalldate, acceptent la valeur Null ), le probleme que j'ai rencontre et le suivant :
Apres mise à jour de mes tables, les champs vides ( champs de type date ) sont remplacés par la valeur '01/01/1900'.
A voir également:

22 réponses

michelatoutfox Messages postés 828 Date d'inscription mardi 5 octobre 2004 Statut Membre Dernière intervention 7 mai 2013 1
26 mai 2009 à 18:38
Bonjour,

Information préalable: SQL Server ne connait pas de champ vide pour les datetime et smalldatetime.

Peux-tu préciser les points suivants, s'il te plait:
Version de VFP?
Version de SQL Server?
Pour accéder à tes données, utilisation de vues distantes, de cursorAdapter, ou bien de SQL Pass-Through?
Quand tu dis 'mise à jour de mes tables', tu parle des tables côté SQL?
0
BOUALLEG Messages postés 3 Date d'inscription jeudi 31 mai 2007 Statut Membre Dernière intervention 27 mai 2009
27 mai 2009 à 09:42
Bonjour Mr.Michel.
j'utilise VFP 9 , et Sql server 2000, et j'utilise les vues distantes.
Apres mise à jour de mes tables, ( validation de la saisie  ) les champs vides (Coté VFP)   sont remplacés par la valeur '01/01/1900' au lieu de la valeur .Null. Coté Sql.
0
michelatoutfox Messages postés 828 Date d'inscription mardi 5 octobre 2004 Statut Membre Dernière intervention 7 mai 2013 1
27 mai 2009 à 10:19
Tu veux dire que quand tu saisis une date vide dans ta vue coté VFP, tu as NULL dans ton champ coté SQL?
tu observes ce '01/01/1900' dans un browse, ou bien dans un controle (textbox, grid, etc...)?
Quel est la valeur du SET NULLDISPLAY? aurais-tu un NVL dans la définition de ta vue? si c'est dans un controle, quelle est la valeur de sa propriété NullDisplay?
0
BOUALLEG Messages postés 3 Date d'inscription jeudi 31 mai 2007 Statut Membre Dernière intervention 27 mai 2009
27 mai 2009 à 15:05
Merci Mr Michel,
1/ Oui, lorsque je saisis un champ ( type date ) vide dans ma vue coté VFP,
j'ai '01/01/1900' dans ce champ  ( type date ) coté SQL? 
j'observe ce '01/01/1900' lorsque j'ouvre la table en utilisant SQL
( Enterprise Manager- base de donnes -ouvrir table ).
2/ Dans mon pgm principale j'ai utilisé la commande :  SET NULLDISPLAY TO ""




 
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
michelatoutfox Messages postés 828 Date d'inscription mardi 5 octobre 2004 Statut Membre Dernière intervention 7 mai 2013 1
27 mai 2009 à 16:38
Tu as nécessairement du code quelque part pour forcer ce champ vide à une valeur déterminée. soit ce code est sur ton serveur SQL (un trigger par exemple), soit il est côté Fox (dans la définition de la vue elle-même, ou dans le code d'un objet).

on est bien d'accord sur le fait que ce que tu constates, c'est quand tu ouvres ta vue directement: soit en ligne de commande avec un use... puis un replace... puis un tableupdate..., soit par un browse depuis un explorateur de projet.
0
panterga Messages postés 67 Date d'inscription dimanche 27 mars 2005 Statut Membre Dernière intervention 5 février 2012 1
1 avril 2011 à 10:01
Bonjour
j'ai un petit souci de maj
j'ai créé un formulaire fox pro 9 sp2 , j'ai créé 3 boutons avec chacun un exemple différent de connexion a sql express 2008 (par odbc)

mon souci est a) pour une vue et une connexion créés ds foxpro ,si je modifie un enreg dans cette vue , j'ai beau faire un tableupdate() la mise à jour n'ai pas enregistré dans ma base sql ...

b) si j'utilise Transact sql donc avec un cursor je peux lire la base sql , modifie un enreg dans mon curseur
faire un update cela fonctionne , mais je trouve cela trés compliqué , en effet sous fox il suffit de se placer sur l'enreg, de modifier et de faire un replace . Alors que là , il faut refaire une requete avec Update et spécifié plein de variable pour retrouver le bon enreg à modifier ds sql . Quel est le meilleur moyen pour ce genre de procédure ?

Mon but est de passer de la base foxpro à sql sans changer mes formulaires ou du moins en adaptant un miminum le code à l'intérieur merci de votre réponse


H Clouet
0
michelatoutfox Messages postés 828 Date d'inscription mardi 5 octobre 2004 Statut Membre Dernière intervention 7 mai 2013 1
1 avril 2011 à 12:51
Bonjour Hervé,

Dans le designer de la vue, il ne faut pas oublier le 6ème onglet, celui qui s'intitule "Critères de mise à jour".

Il faut cocher "Envoyer les mises à jour", mais aussi, pour chacun des champs pouvant être mis à jour, il faut le cocher (la case grise sous le symbole en forme de crayon) .
Et il faut aussi définir un ou plusieurs champs qui seront la clé d'identification des lignes à mettre à jour. Si ta table a une clé primaire (ce qu'elle devrait avoir, si elle n'en a pas, il faut reprendre ton modèle de données), alors VFP a présélectionné le(s) champ(s) qui définit cette clé primaire comme champ(s)-clé(s).

ces 3 choix correspondent à du code visible dans la fenètre SQL de la vue
mise à jour : DBSetProp(ThisView,"View","SendUpdates",.T.)
champ clé : DBSetProp(ThisView+".nom_du_champ","Field","KeyField",.T.)
champ à mettre à jour : DBSetProp(ThisView+".nom_du_champ","Field","Updatable",.T.)

Pour ce qui concerne l'utilisation de SQL Pass-Through (SPT), il faut en effet utiliser (donc écrire) les commandes de mises à jour dans un ordre SQLexec.

Si tu veux avoir le moins de modifs à faire dans tes formulaires actuels, c'est probablement en utilisant des vues ou des CursorAdapter, mais on y arrive aussi avec du SPT. ça dépend de ton code actuel, de la façon dont il est écrit, de ta façon d'utiliser les classes et/ou les fichiers de prodédures.
0
panterga Messages postés 67 Date d'inscription dimanche 27 mars 2005 Statut Membre Dernière intervention 5 février 2012 1
19 oct. 2012 à 18:32
Bonjour Michel
Petite question concernant SQL peux t'on exporter facilement une table (de sql) en fichier TXT afin qu'elle soit importée dans un dbf .

j'ai fait un essai avec une table DBF de 100000 enreg en faisant copy to fichier.txt type sdf cela met 1/2 seconde
Je pourrais bien sur faire une boucle sous SQL pur creer le fichier texte , mais je crains que cela ne soit trop long
Donc y a t'il une façon aussi simple que foxpro ?

Bien sur , je peux aussi utiliser les cursor ... mais je prefere trouver une solution autre car le but est de faire la transition de foxpro vers Visual studio en utilisant SQL server .

amitiés

H Clouet
0
michelatoutfox Messages postés 828 Date d'inscription mardi 5 octobre 2004 Statut Membre Dernière intervention 7 mai 2013 1
20 oct. 2012 à 10:03
Bonjour Hervé,

content de te "revoir" ici!

Tu veux exporter une table deSQL Server en fichier texte, c'est bien ça? Est-ce que c'est une opération que tu comptes faire une seule fois, toi-même, ou bien ça sera répétitif? si c'est répetitif, ça sera indépennat de tout programme (autonome), ou bien ça serait inclus dans un programme?

1) une seule fois : tu disposes dans SQL Server Management Studio d'un assistant exportation qui te génère ce fichier texte, il suffit de suivre les consignes (comme pour tout assistant ). Pour lancer cet assistant, un click droit sur la base de donnée de départ, puis Tâches, puis Exporter des données.

2) répétitif autonome: il te faut créer un package SSIS depuis SQL Server Management Studio (même assistant que précédemment, juste la fin est différente), et l'exécuter sur la machine de destination avec l'utilitaire ad-hoc

3) répétitif intégré dans un programme: il te faut regarder la syntaxe de l'utilitaire SQL Server "bcp"
0
panterga Messages postés 67 Date d'inscription dimanche 27 mars 2005 Statut Membre Dernière intervention 5 février 2012 1
20 oct. 2012 à 10:34
Hello Michel
merci de ta sollicitude, il est vrai que je pense souvent à l'équipe, mais que beaucoup de travail en ce moment et quelques soucis m'ont dirigé sur d'autres horizons, mais voilà le boulot est nécessaire ....

en fait je désire l'intégrer dans un 1er temps dans un programme Fox car cela récurrent ; j'avais bien vu le prg BCP
mais je pensais qu'il pouvait y avoir une commande SQL ; BCP doit se lancer sous dos non ?

Ensuite j'ai une dernière question (je ne suis pas trop à l'aise avec SQL server) , j'ai bien suivi le tuto sur SQL et les vues avec FOX (super d'ailleurs) cela fonctionne parfaitement ; peux t'on se connecter et utiliser une base SQL (avec fox bien sur) sans pour autant faire la connexion et les vues à l'avance (je veux dire dans les onglets prévus) mais le faire en FLY . Je te pose cette question car le but est de donner la base SQL (et le prog fox) aux clients sans avoir trop de manip à faire chez eux car le nom du serveur , le nom de la connexion etc .... n'est pas toujours faciles à identifier , de plus certains clients ont déjà un SQL SERVER d'autres rien du tout etc ...
D'ailleurs y a t'il un tuto d'installation d'une base SQL chez un client (dans les 2 cas) ?

Je te souhaite un bon Week end au plaisir de te revoir en live !!! et non en Fly
H Clouet
0
panterga Messages postés 67 Date d'inscription dimanche 27 mars 2005 Statut Membre Dernière intervention 5 février 2012 1
20 oct. 2012 à 12:58
Re bonjour michel
Alors j'ai un peu avancé mais je me pose encore des questions
Pourquoi après un CREATE SQL VIEW ..... et après vérification de la vue (ds les prop fox) la case à cocher 'envoyer mise à jour' est grisée si on a pas défini un index ? est on obligé d'indexer la vue pour pouvoir la modifier ?



voici mon code
CREATE SQL VIEW dede2 REMOTE CONNECTION "Basesql" as select * from mairie
USE dede2

DBSETPROP("dede2","VIEW","SendUpdates",.T.)
DBSETPROP("dede2.nom","FIELD","KeyField",.T.) ici j'ai du mettre .T. sinon il y a erreur ????
DBSETPROP("dede2.nom","FIELD","Updatable",.T.)

BROWSE * ici je change le nom par exemple

TABLEUPDATE(1,.T.,'dede2')

USE IN dede2

mais cela ne met pas à jour la table mairie de la base SQL !!!! pourquoi ?
merki de ta réponse ....

H Clouet
0
panterga Messages postés 67 Date d'inscription dimanche 27 mars 2005 Statut Membre Dernière intervention 5 février 2012 1
20 oct. 2012 à 14:02
RE Re bonjour michel

alors j'ai déplacé une ligne (use dede2)

CREATE SQL VIEW dede2 REMOTE CONNECTION "Basesql" as select * from mairie
DBSETPROP("dede2","VIEW","SendUpdates",.T.)
DBSETPROP("dede2.nom","FIELD","KeyField",.T.)
DBSETPROP("dede2.nom","FIELD","Updatable",.T.)
USE dede2
browse
*tt=TABLEUPDATE(1,.T.,'dede2')

USE IN dede2


et cette fois ci cela change dans la base SQL mais tous les enreg ont pris le même nom (celui changé dans un seul enreg)

je suis un peu perdu .....

H Clouet
0
michelatoutfox Messages postés 828 Date d'inscription mardi 5 octobre 2004 Statut Membre Dernière intervention 7 mai 2013 1
20 oct. 2012 à 14:06
Le mieux, sur les forum, c'est d'ouvrir un sujet pour chaque question technique différente (par exemple ici, un sujet sur l'export et un sujet sur les vues)

Bon, comme les 2-3 questions sont là, je vais y répondre.

1) l'export
cest bien bcp qu'il te faut utiliser, c'est le plus simple. c'est une commande que tu peux parfaitement lancer depuis VFP par le biais d'un ShellExecute. Regarde sur le site d'AtoutFox, dans ma contrib sur LocalDB, je donne un exemple d'utilisation de ShellExecute.

2) la vue distante
c'est prévu pour être préparée à l'avance (je sais, on peut faire un CREATE VIEW à la volée, mais c'est une aberration en terme de perf). Dans la vue que tu prépares, tu vas mentionner tous le code du select, les champs à mettre à jour, etc etc... bref, tout ce qui fait une vue en dehors de la connexion.
Et à l'exécution dans VFP, tu vas faire un USE ma_vue CONNSTRING la_bonne_chaine_de_connexion_pour_cet_utilisateur. En bref, tu codes une fois, et il n'y a que les paramètres de connexion qui sont différents.

3) la mise à jour de la vue distante
Ta table SQL sous-jacente DOIT avoir une clé primaire. règle d'or absolue, toute table doit avoir une clé primaire (une primary key). Et c'est cette clé primaire qui va être le champ-clé de ta vue. Est-ce le cas ici? peux-tu donner le code de création de cette table dans SQL Server (avec la clé primaire)?
0
panterga Messages postés 67 Date d'inscription dimanche 27 mars 2005 Statut Membre Dernière intervention 5 février 2012 1
20 oct. 2012 à 16:35
Alors j'ai bien avancé , j'ai compris pour la clé primaire , et j'ai réussi à modifier la vue que cela soit en utilisant du code ou en modifiant dans un grid ... en fait il faut absolument utiliser
do while not flock()
enddo
....
tableupdate()
unlock

sinon cela fait n'importe quoi ....(tous les noms changent avec la même variable ou ne change pas etc ...)
_____________________________________
Donc si j'ai bien compris pour la connexion sur un autre site , je prépare ma vue dans mon prog , cela veut dire tout de même que je dois declarer un ODBC , le même nom de SQL server etc ... chez le client ... je pensais que cela pouvait être plus simple comme les sql .SDF !!!! bon tant pis

pour le code de la table dans SQL , je ne l'ai pas fait par code mais par le management ..mais apparemment le problème venait de la vue qui elle aussi doit être avec une clé pour pouvoir être cocher "MISE A JOUR" sinon pas de maj dans SQL me trompe je ?

H Clouet
0
michelatoutfox Messages postés 828 Date d'inscription mardi 5 octobre 2004 Statut Membre Dernière intervention 7 mai 2013 1
20 oct. 2012 à 19:26
Hervé,

je n'ai JAMAIS utilisé de flock(). c'est absolument inutile. regarde du coté de CURSORSETPROP("BUFFERING").

pour que ton tableupdate fonctionne correctement, il FAUT une clé primaire à la table. Je t'avais demandé le code de CREATE TABLE de cette table, avec la clé primaire.

Si ta table a une clé, alors VFP va la trouver et te la proposer en clé de mise à jour pour ta vue. Si tu as déjaà créé la vue avant de mettre la clé sur la table, tu dois recommencer la création de la vue (VFP ne sait pas se mettre à jour tout seul en create view). cette clé sur la vue DOIT etre la même que celle de la table, sinon tu risques des comportement bizarres lors des mises à jour.

Et non, tu n'as pas bien compris pour la connexion. On est bien d'accord sur le fait que tous tes clients ont bien installé le Client SQL Server (voir dans mes contribs sur AtoutFox comment l'installer depuis VFP). Et on est aussi d'accord sur le fait que tu connais à l'avance le nom de la database et des tables (ça c'est toi qui les crées toi-même).
A partir de là, il ne manque plus que le nom du serveur et de son instance, et éventuellement le nom d'utilisateur SQL si tu es en authentification mixte. Si le serveur SQL du client existe avant toi, il connait ces informations, et tu peux les récupérer pour les mettre dans un fichier texte qui te servira à alimenter la chaine de connexion. Si c'est toi qui installe un serveur SQL chez ton client, alors tu connais aussi ces informations. Et si nécessaire, tu peux utiliser un DSN fichier ou un DSN système pour stocker cette info.
Donc je ne vois pas où est le problème...

Dans SSMS (Sql Server Management System) tu peux demander la génération du code de CREATE TABLE. Click droit sur le noeud de la table dans l'explorateur d'objet.
0
panterga Messages postés 67 Date d'inscription dimanche 27 mars 2005 Statut Membre Dernière intervention 5 février 2012 1
21 oct. 2012 à 13:09
Bonjour Michel
voici la génération de la table:


USE [DataM]
GO

/****** Object: Table [dbo].[mairie] Script Date: 10/21/2012 13:08:32 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[mairie](
[effac] [nchar](1) NULL,
[numapp] [numeric](2, 0) NULL,
[numtic] [numeric](8, 0) NULL,
[numrecap] [numeric](8, 0) NULL,
[date] [date] NULL,
[prix] [numeric](8, 2) NULL,
[paie] [nchar](1) NULL,
[groupe] [numeric](2, 0) NULL,
[clas] [numeric](2, 0) NULL,
[regis] [numeric](2, 0) NULL,
[marche] [nchar](2) NULL,
[nom] [nvarchar](20) NULL,
[ncom] [int] NULL,
[quant] [numeric](7, 2) NULL,
[quant1] [numeric](7, 2) NULL,
[prixu] [numeric](7, 2) NULL,
[expo] [nchar](5) NULL,
[unit] [nchar](7) NULL,
[taxe] [nchar](10) NULL,
[prixt] [numeric](7, 2) NULL,
[numchq] [nvarchar](15) NULL,
[flag] [nchar](1) NULL,
[prixe] [numeric](7, 2) NULL,
[date1] [nchar](10) NULL,
[date2] [nchar](10) NULL,
[adres] [nvarchar](30) NULL,
[cpvil] [nvarchar](40) NULL,
[observ] [nvarchar](80) NULL,
[abo] [nchar](1) NULL,
[tva] [nchar](1) NULL,
[numplace] [nchar](3) NULL,
[compteur] [numeric](2, 0) NULL,
[commenta] [nvarchar](30) NULL
) ON [PRIMARY]

GO

merci ...................


H Clouet
0
michelatoutfox Messages postés 828 Date d'inscription mardi 5 octobre 2004 Statut Membre Dernière intervention 7 mai 2013 1
21 oct. 2012 à 16:38
Bon, on va pouvoir avancer...

Dans SSMS, tu vas dans les options, tu cherches Explorateur d'objets, puis Scripts, et là tu vas dans les Options de Table et de vue. Tu vas mettre à True les valeurs suivantes:
* Générer un script pour les clés étrangères
* ... pour les clés primaires
* ... pour les clés uniques
* ... pour les contraintes CHECK
* ... pour les index
* Inclure la propriété IDENTITY

tu valides ces modifs par un click sur le boton OK, et tu me re-génère le script de la table, comme ça il y aura tous les renseignements dont on a besoin pour travailler.

Parlons de cette table maintenant. Il y a de grosses erreurs structurelles, à corriger en urgence à mon avis sinon tu n'auras que des incohérences dans VFP:
1) n'utilise pas de nChar ou de nVarchar comme type de données pour les caractères. le n devant le type signale que c'est destiné aux données Double-Byte (unicode en général). Inutile en France, consomme le double de place en RAM et sur disque, risque parfois de mal s'afficher dans VFP.
2) je ne vois pas de colonne ( en SQL, on ne parle pas de champs mais de colonnes) qui pourrait servir de clé primaire. En effet, toutes tes colonnes sont NULLables, et par définition une clé primaire ne doit pas l'être.
Prends l'habitude d'utiliser dans toutes tes tables une colonne spécifique INT IDENTITY (c'est à dire entier autoincrémenté) qui ne servira qu'à être la clé primaire. Et c'est cette colonne que tu coches dans tes vues VFP comme champ clé (VFP devrait même te la cocher automatiquement)
Comprends bien que quand tu envoies un TABLEUPDATE, VFP transmet à l'ODBC qui transmet à SQL Server une instruction qui lui dit UPDATE ma_table SET ma_colonne=cett_valeur WHERE <la clé primaire vaut ceci>
Ce WHERE est automatiquement généré par VFP, et c'est la seule manière pour SQL Server de savoir quelle(s) ligne(s) il doit mettre à jour.

Corrige cette table "mairie", renvoie le script complet, et ensuite on avancera dans la bonne direction. Sinon, pour l'instant, c'est dans le mur que tu vas!
0
panterga Messages postés 67 Date d'inscription dimanche 27 mars 2005 Statut Membre Dernière intervention 5 février 2012 1
21 oct. 2012 à 18:18
Michel
Voici la table corrigée :

USE [DataM]
GO

/****** Object: Table [dbo].[mairie] Script Date: 10/21/2012 18:18:15 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

SET ANSI_PADDING ON
GO

CREATE TABLE [dbo].[mairie](
[effac] [char](1) NOT NULL,
[numapp] [numeric](2, 0) NOT NULL,
[numtic] [numeric](8, 0) NOT NULL,
[numrecap] [numeric](8, 0) NOT NULL,
[date] [date] NOT NULL,
[prix] [numeric](8, 2) NOT NULL,
[paie] [char](1) NOT NULL,
[groupe] [numeric](2, 0) NOT NULL,
[clas] [numeric](2, 0) NOT NULL,
[regis] [numeric](2, 0) NOT NULL,
[marche] [char](2) NOT NULL,
[nom] [char](20) NOT NULL,
[ncom] [int] NOT NULL,
[quant] [numeric](7, 2) NOT NULL,
[quant1] [numeric](7, 2) NOT NULL,
[prixu] [numeric](7, 2) NOT NULL,
[expo] [char](10) NOT NULL,
[unit] [char](10) NOT NULL,
[taxe] [char](10) NOT NULL,
[prixt] [numeric](7, 2) NOT NULL,
[numchq] [char](15) NOT NULL,
[flag] [char](10) NOT NULL,
[prixe] [numeric](7, 2) NOT NULL,
[date1] [char](10) NOT NULL,
[date2] [char](10) NOT NULL,
[adres] [nvarchar](30) NOT NULL,
[cpvil] [char](40) NOT NULL,
[observ] [char](80) NOT NULL,
[abo] [char](10) NOT NULL,
[tva] [char](10) NOT NULL,
[numplace] [char](10) NOT NULL,
[compteur] [numeric](2, 0) NOT NULL,
[commenta] [char](30) NOT NULL,
[identity] [int] NOT NULL,
CONSTRAINT [PK_mairie] PRIMARY KEY CLUSTERED
(
[identity] ASC
)WITH (PAD_INDEX OFF, STATISTICS_NORECOMPUTE OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

SET ANSI_PADDING OFF
GO

est ce correct ? merci encore de tes conseils avisés ....

Hervé .
0
panterga Messages postés 67 Date d'inscription dimanche 27 mars 2005 Statut Membre Dernière intervention 5 février 2012 1
21 oct. 2012 à 18:38
J'ai voulu mettre la vue ds FOXP j'ai le message

erreur de connectivité
ODBC SQL Server Driver
Syntaxe incorrecte vers le mot clé "Identity"


H Clouet
0
michelatoutfox Messages postés 828 Date d'inscription mardi 5 octobre 2004 Statut Membre Dernière intervention 7 mai 2013 1
21 oct. 2012 à 19:14
J'ai du mal m'expliquer: la colonne pour la clé primaire ne s'appelle pas IDENTITY : c'est un mot-clé réservé de SQL server, qui correspond au mot-clé AUTOINC de VFP.

Tu peux la nommer comme tu veux (en général on l'appelle PK_nom_de_la_table, ou bien ID_nom_de_la_table, ou bien dans l'autre sens nom_de_la_table_PK...)
tu lui met comme type de données INT, ça c'est OK tu l'as fait, mais tu lui donnes l'attribut IDENTITY (donc autoinc) - pour ça regarde dans le bas de l'écran de SSMS où tu définis cette colonne, il y a les propriétés des colonnes, et tu y trouveras "Spécification du compteur". tu ouvres cette rubrique, et tu complète en spécifiant Oui pour "Est identité"

Et là, on y sera presque, pour la définition de la table. Il restera juste à se demander quels colonnes sont obligatoirement remplies, et pour celles-là seulement alors il faudra les mettre en NOT NULL.

une fois que ta table sera créée, tu peux créer une vue dans VFP qui pointe sur cette table.
0
Rejoignez-nous