Importer un dump SQL dans VFP9

Bonjour,

Je dispose d'une application construite sur VFP9 réalisée par un prestataire.
Pour l'utiliser au sein d'une appli web, j'ai exporté les données dBase vers un serveur mysql et construit une application dessus.

J'ai aussi réalisé de nombreuses corrections (plusieurs milliers!) sur les données, parce que le mode de saisie proposée par l'applicatif VFP, c'est-à-dire le format des données exportées, ne me convenait pas.

Aujourd'hui, mon prestataire me dit qu'il a modifié le mode de saisie.

C'est une bonne chose, mais je souhaiterais qu'il puisse intégrer simplement toutes les corrections (certaines manuelles, d'autres automatiques) que j'ai déjà réalisées.

Conditions:
1. Je n'ai pas accès à VFP. De toutes les façons, je ne connais pas le langage
utilisé pour communiquer avec cette base.
2. Je ne peux pas demander au prestataire d'écrire une ligne spécifique de code, parce que je n'ai pas de budget pour cela.
3. En revanche, dans le cadre d'un contrat de maintenance, je peux lui demander de m'intégrer un dump que je lui fournis si la manip est simple. D'où:

Question:
Si je fournis un fichier texte encodé en ANSI avec des UPDATE SQL standards, est-ce
ça passe ?

Ex: une table ma_table.dbf, et les colonnes ID (int), COL1 (varchar) et COL2 (varchar).

UPDATE ma_table.dbf SET COL1 = 'Voyage au bout de la nuit', COL2 = 'Louis-Ferdinand Céline' WHERE ID=000123;

UPDATE ma_table.dbf SET COL1 = 'La peste', COL2 = 'Albert Camus' WHERE ID=000124;

etc.

Sinon, que dois-je modifier dans les commandes précédentes pour importer ce fichier directement dans VFP ?

Ou bien, sous quelle autre forme est-ce simplement importable dans VFP (CSV ? XLS ?XML ?)

Cordialement,

PG


PS: Je pourrais demander au prestataire, mais je préfère débrousailler un peu avant pour ne pas l'embrouiller.

Bonjour,

VFP intègre nativement un sous-ensemble de la norme SQL99, donc les instruction UPDATE normalisées sont directement interprétables depuis VFP.

Attention, en VFP, il n'y a pas de caractère de terminaison d'instruction, et le point-virgule est justement le caractère de continuation de ligne. Il faut donc enlever ces points-virgules pour que VFP puisse exécuter ces instructions.
Attention aux formats des dates, vois avec ton prestataire ce qu'il préfère.
Attention également aux chaines de caractères comportant des caractères identiques aux délimiteurs, VFP ne dispose pas de caractère d'échappement, mais propose 3 séparateurs de chaines possibles, à utiliser en fonction de contenus complexes : la quote simple ', la double-quote " et les crochets carrés [ ] .

Mais depuis VFP, on peut aussi importer du CSV, du XLS, du XML, etc..

Celà dit, ce que tu demandes n'a strictement rien à voir avec un dump, c'est un script des données!

Bonjour Michel et merci pour ta réponse.

Tu as raison, ce n'est pas un dump. J'étais parti avec l'idée de faire un dump mais ce sont des modifications des données existantes qui m'arrangent davantage. J'aurais dû changer le titre.

Encore deux questions, cette fois-ci en rapport avec XLS et/ou XML.

1. Est-ce que les éventuels problèmes d'échappement liés à l'utilisation de
caractères délimiteurs de VFP dans les strings se posent aussi avec un import Excel ou XML ? Ou bien est-ce que VFP les "convertit" comme il faut ?

2. Avec un import XLS ou XML, est-ce que je peux réaliser un update de certains champs (équivalent de la commande SQL UPDATE) sur des enregs existants ou bien faut-il d'abord vider la table puis importer les enregs complets (avec tous leurs champs).

2'. Si on peut réaliser un update sur des enregs existants sans vider la table, faut-il faire figurer tous les champs dans le fichier Excel (ou XML) ou seulement les champs à modifier ?

Cordialement,

PG

pour la quetion 1, il n'y a pas de pb d'échappement à gérer dans les xls et xml, puisque ces formats de fichier ne les gèrent pas non plus.

pour les questions 2 et 3, je dirais que ... ça dépend !
techniquement, ce que tu décris est faisable, mais pas directement, ça demande du code VFP. Pour ton prestataire, c'est plus de travail, en engageant une responsabilité supplementaire pour lui (donc c'est probablement une presta hors contrat, et tu n'as pas le budget).

la solution d'un fichier texte contenant les commandes update à exécuter est à mon avis la plus simple à mettre en oeuvre, et celle qui engage uniquement ta responsabilité sur les contenus.

Je vais suivre ton conseil Michel.

Pour les dates, je n'ai pas de maj à faire, donc le pb ne se posera pas.

Pour les chaînes, je vais chercher un peu de doc sur les délimiteurs VFP et les séparateurs proposés ("", '' ou []).

Merci encore pour ton aide.

PG

pour les chaines, c'est très simple: les 3 délimiteurs sont autorisés. donc si tu as une chaine qui contient par exemple
l'auteur dit "bonjour"
tu vas encadrer ta chaine avec des crochets
UPDATE matable SET col1 = [l'auteur dit "bonjour"] WHERE id = 1

il y a juste le cas où la chaine contient à la fois les 3 délimiteurs que ça devient plus compliqué

En fait, dans les chaînes, j'ai:

- des quotes ' (ex: l'arbre)
- des guills (ex: il m'a dit "bonjour")
- des parenthèses (ex: blabla (blibli) blublu)
- des crochets (ex: blabla [blibli] blublu)
- des ponctuations (. ... , ! ? : ;) comme dans des phrases

Si j'écris systématiquement des updates avec des crochets [...] est-ce que ça peut résoudre tous les pbs ? Et dans ce cas, est-ce que la présence de crochets dans la chaîne lui pose un pb ?

Ex: UPDATE matable SET col1 = [l'auteur[NDLR] a écrit...] WHERE id = 1

Dernières questions parce que tu n'as pas que ça à faire je suppose.

1. Tu notes la table matable. Faut-il la nommer :
UPDATE matable SET...
ou
UPDATE matable.dbf SET...

2. Dans le fichier texte, il reconnaît le passage d'une requête à la suivante par le retour Windows: CR LF ?
UPDATE .... CR LF
UPDATE ... CR LF

Encore merci Michel, j'ai tout ce qu'il me faut à présent.

PG