mer. 18 novembre 2015, 11h51
OlivierH
atoutfox.public.association
Re: DBC to SQLserver -- champs uniqueID
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
Le 18/11/2015 11:12, FoxInCloud a écrit :
> Michel, Olivier,
>
> Merci d'accompagner mes premiers pas avec SQLserver et l'upsizing wisard
>
> 1- J'utilise bien sedna/upsizing de VFPx en mode 'quiet' piloté par programme
>
> 2- dans le DBC actuel, toutes les tables et vues correspondantes ont:
DBSetProp(m.ThisView/Table+".PK", "Field", "DefaultValue", "sys2015()")
> si je conserve ce système, seul VFP pourra ajouter des enregistrements, à moins de reproduire sys(2015) dans SQLserver (comme Luc Gilot crée des fonctions à la VFP dans PostgreSQL) et donner cette valeur par défaut aux colonne correspondantes (au moyen d'une 'contrainte' si j'ai bien compris).
>
> 3- Pour utiliser des clés primaires integer autoincrement dans SQLserver, il faut:
> - comme le DBC VFP est répliqué sur 2 sites synchronisés (LAN et WEB), m'assurer que, pour chaque table, un seul site créé des enregistrements (a priori vrai mais y'a intérêt à bien s'en assurer)
> - migrer la base VFP vers des clés auto-incrément
> - adapter la synchronisation aux clés VFP auto-incrément (AI) (supprimer l'AI, ajouter les nouveaux enr., calculer la nouvelle clé, rétablir l'AI, le tout nécessitant un accès exclusif aux tables concernées, ce qui est fort contraignant voire impossible, la synchro des données étant faite à chaud plusieurs fois par jour).
>
> Bref je vais évoquer tous ces scénarios avec le BI manager du client (et expert SQL server) et décider avec lui ce qu'il préfère.
>
>
> Le mer. 18 novembre 2015, 09h17 OlivierH a écrit :
>> Bonjour Thierry
>>
>> Pour compléter ce que dit michel :
>>
>> 1- j'ai utilisé l'upsizing de michel, il corrige des bugs que sedna ne
>> gère pas, ca fait longtemps mais je crois de mémoire les varchar(max) et
>> autre correspondances de champs. Donc il est plus sur et en plus tu as
>> accès aux sources.
>>
>> 2- L'uniqueIdentifier est utilisé dans le cadre ou tu as plusieurs App
>> différentes qui utilise la même base. C'est sous le format d'un Guid et
>> non de 10car, cela t'assure plus de securité sur l'unicité de la ligne.
>>
>> Par exemple si tu as une app smartphone android ou ios qui discute en
>> RestApi avec ton sqlserver, et que cess app sont dites deconnecté et que
>> tu synchronises ta base avec une base local cela peut être utile.
>> Sinon int ou bigint suffit à la plupart des besoins.
>>
>>
>>
https://msdn.microsoft.com/fr-fr/library/ms187942%28v=sql.120%29.aspx>>
>>
http://stackoverflow.com/questions/1151625/int-vs-unique-identifier-for-id-field-in-database>>
>> ps : dans mon appli fox : j'avais des clés en char sur 12 car, j'ai mis
>> en place les int dans mes tables, afin de garder les deux mecanismes
>> pour une retro compatibilité avec mon appli lan fox.
>> Mais sur sqlserveur tous les id sont en clé primaire, ainsi que les
>> tables etrangère en int, cela sert juste à l'appli fox en lan pour
>> rechercher ses petits.
>>
>> J’espère d'avoir aidé à choisir la bonne solution.
>>
>> Olivier,
>>
>>
>>
>>
>>
>> Le 17/11/2015 21:09, Michel L?vy a écrit :
>>> Bonsoir Thierry,
>>>
>>> quelques pistes:
>>>
>>> 1) j'ai traduit et corrigé l'upsizing wizard il y a 7 ans de ça, tu ferais mieux de traiter ton besoin spécifique dans le code source disponible sur CodePlex (
http://vfpx.codeplex.com/downloads/get/59511)
>>>
>>> 2) du point de vue du moteur de SQL server, les clés primaires en uniqueidentiifer sont toujours moins performantes que celles en entiers autoincrémentés (c'est du à la structure physique des index clustered)
>>>
>>> 3) si toutefois tu veux absolument cette transposition, alors regarde ce que tu peux faire avec la table typemap.dbf qui est incluse dans l'upsizing wizard. Mais je pense que tu n'as rien à y gagner par rapport à tes C(10). tu peux parfaitement choisir d'avoir des clés primaires attribuées par l'application cliente, et conserver ton attribution de sys(2015)
>>>
>>> 4) en SQL, les clés primaires sont des définitions structurelles, et l'upsizing wizard peut te générer ce DDL. Attention à bien préciser que tu veux une RI déclarative (structurelle), et non pas procédurale (dans les triggers, beaucoup plus lent et générateur potentiel de deadlocks)
>
>
>
Lister code source du projet C_TANG - 06/12/2015 10h06
Roland38 - 13/11/2015 11h33
Flux RSS des derniers messages
Derniers messages
Informations
