mer. 18 novembre 2015, 12h21
FoxInCloud (Th. Nivelet)
France
atoutfox.public.association
Re: DBC to SQLserver -- champs uniqueID
Merci Olivier,
Ta solution est une 3ème variante avec 2 jeux de clés primaires car tes bases DBC et SQL coexistent.
Dasn mon cas c'est une transition de DBC vers SQLserver qui doit être progressive car plusieurs applications sont concernées, gérées par différents développeurs dans différents pays ;
aussi je voudrais :
- un upsizing 100% automatique pour être exécuté à l'identique par chaque développeur
- convertir les vues locales actuelles en cursorAdapter (automatiquement le plus possible, projet VFPx en cours d'examen)
- avec un switch global d'application, passer les CAD en mode local ou remote pour tester aisément chaque mode sans figer les applications qui évoluent sans cesse.
Note : si toutes les contraintes sont côté SQLserver, à quoi te servent les clés primaires VFP?
Le mer. 18 novembre 2015, 11h51 OlivierH a écrit :
> Thierry
>
> Je réponds au point n° 3 qui a été mon cas.
>
> J'ai plusieurs sites avec une base local Dbf qui envoit sur une base
> centralisée SqlServer.
>
> on part sur l'exemple table customer.
>
> Coté vfp :
>
> cus_id : champs en int clé non primaire mais indexée
> cus_id_vfp : char(16) code societe + cle vfp en padl soit pour le site
> 000001 , sa ref :0000000123 donc le résultat : 0000010000000123
>
> Coté Sql Server :
>
> cus_id : en autoinc et clé primaire.
> cus_id_vfp : char(16) indexé en unique.
>
> Si mon appli vfp enregistre un customer, au moment de l'enregistrement
> j'ai mon cus_id à -1. Je l'envois à l sql server , et je recupère la clé
> autoinc que je mets à jour sur Vfp.
>
> Si j'insère coté SqlServer en mode web, la clé se rempli en auto et mon
> champs cus_id_vfp est vide car non rempli avec vfp.
>
> Toutes mes contraintes (relation) sont du coté de SqlServer, et j'en ai
> aucun coté vfp. Et au fur et à mesure du temps, je parcourais chaque
> formulaire pour que vfp saisisse en direct dans la table SqlServer, afin
> de ne plus avoir de saisie sur des DBF.
>
> Je concède que ceci n'est pas une solution idéale, mais correspondait à
> mes besoins.
>
> Si ton client veut absolument faire de la synchronisation, et que ses
> données sont sensibles aux relations (comme une banque ou comptable), je
> lui conseillerais que SqlServer s'occupe des synchronisation entre un
> SqlServer local et SqlServer Distant.
>
> Car il a les mecanismes en interne pour le faire. Mais cela coute cher
> en developpement, et comme foxpro est fait pour lire et ecrire sur sql
> server, c'est mieux de partir sur cette solution, comme cela tous ses
> sites sont reliés en temps réel.
>
>
> cdlt,
> Olivier
Permalink : http://www.atoutfox.org/nntp.asp?ID=0000016890
Lister code source du projet C_TANG - 06/12/2015 10h06
Roland38 - 13/11/2015 11h33
Flux RSS des derniers messages
Derniers messages
Informations
