2010-09-01 12 views
0

et encore une fois une axapta-question (fonctionnant sur ax 2009 et sql-server 2008 r2): qui est exactement le moment où les jeux de données insérés ou mis à jour sont stockés dans la base de données concernant?axapta insertion de table/mise à jour

le but est d'appeler une procédure stockée sur le serveur sql qui transfère les données des tables hache (par exemple inventtable) vers une autre table (non générée avec axapta). l'exécution de la procédure stockée via odbc depuis axapta sur l'une des méthodes-table (même après super()) déclenche la procédure stockée, mais les données qui viennent d'être ajoutées ou modifiées dans ax ne sont pas trouvées lors de la sélection via smss (select * de dbo.inventtable). Le seul endroit où je sais encore où les données sont déjà stockées dans db est sur les méthodes sur la source de données sur le formulaire concerné, mais ce serait calme moche, puisque les données pourraient être éditées via n formes de ax.

est-il donc un moyen de mettre l'appel sur la table à la place sur les sources de données des formulaires?

merci pour des conseils à l'avance!

Répondre

1

Les données AX est « stocké » dans la base de données au point de doInsert()/doUpdate() ou super() appels à insert()/update() méthodes. Cependant, comme Jay l'a mentionné, les enregistrements ne seront pas visibles pour les autres transactions (à moins que vous n'autorisiez explicitement les sélections sales/non validées). Il peut donc ne pas être visible à votre procédure stockée.

Je ne recommanderais pas l'appel des procédures stockées dans insert()/update() de toute façon que cela a des implications de performance, et vous dépendez maintenant d'encore une autre base de données en vie!

Le chemin à parcourir:

  1. insertion/mise à jour du journal dans un tableau distinct à cette fin (envisager d'utiliser l'enregistrement de base de données standard).
  2. Depuis l'autre base de données, surveillez régulièrement le journal pour rechercher de nouveaux enregistrements (par exemple toutes les 15 secondes).
  3. Effectuez votre insertion/mise à jour dans l'autre base de données en fonction d'une jointure du journal et de la table AX.

table layout journal (un des millions):

  • LogType - 1 = insert, 2 = mise à jour, 3 = supprimer
  • logstatus - 0 = non transféré, 1 = sous transfert, 2 = transféré, 3 = erreur ???
  • RefRecId - RECID de l'enregistrement AX
  • RefTableId - tableid de table AX (si vous devez vous connecter plus d'une table)
  • RefCompanyId - Société de l'enregistrement AX (peut-être la table est pratiquement partagée)

Recommandations:

  1. Utilisez rECID comme la clé de jonction et n'oubliez pour permettre l'indice rECID sur la table AX. N'oubliez pas de sélectionner sur DATAAREAID (doit être orthographié de cette façon) aussi bien.
  2. Mettez à jour le LogStatus à 1 avant la jointure et à 2 après la jointure et la mise à jour.
+0

fonctionne comme prévu. la seule différence est que j'utilise fusion au lieu de mettre à jour/insérer/supprimer! merci pour votre indice! – Nico

+0

Fusionner sur le serveur SQL: http://technet.microsoft.com/en-us/library/bb510625.aspx Il ne gérera toutefois pas les suppressions. –

0

Mettre l'appel après l'appel super() dans la méthode de la table insert() ou update() est l'endroit approprié pour cela, mais à moins que vous n'effectuiez une lecture non validée, l'instruction select de votre procédure stockée les données jusqu'à ce que la transaction dans AX soit validée.

Pourriez-vous utiliser la connexion ODBC de X ++ pour écrire directement dans la table externe plutôt qu'indirectement via une procédure stockée?

+0

ODBC ne peut pas être utilisé à ce stade - je doute que x ++ soit capable de répondre à mes besoins de requêtes sql à ce stade;) – Nico