Oplever du at Dynamics NAVs udviklingsklient hænger med “Not Responding” når du forsøger at synkronisere tabelændringer?
Hvis du samtidigt kører med NavUserPassword authentication (eller rettere – IKKE kører med Windows authentication) på din Dynamics NAV service instans – så har du allerede fundet fejlen. Eller rettere begrænsningen.
Når der skal synkroniseres tabelændringer tager Dynamics NAV udviklingsklienten fat i Dynamics NAV servicen for at få den til at køre evt. opgraderings codeunits og/eller validere at ændringen kan ske uden datatab.
Men desværre er den ikke intelligent nok til at den kan finde ud af at logge ind med andet end Windows authentication. Dvs. den er ikke i stand til at vise en evt. login-boks, som jo er krævet ved fx NavUserPassword. Derfor er resultatet sådan set at den går en tur rundt om de uendelige bit-marker (og det tager laaaang tid at gå rundt om noget der er uendelig) – dvs. den hænger med “Not Responding”.
Slår du Dynamics NAV servicen ned, finder Dynamics NAV udviklingsklienten godt nok ud af det og viser en fejl om at den sørme ikke kunne kontakte Dynamics NAV servicen.
Workaround ligger lige for – du er nødt til at opsætte en ekstra Dynamics NAV service, der kører Windows authentication og som du kan bruge når du skal lave tabel synkronisering. Så kan du jo nøjes med at starte den service når du skal bruge den, hvis det kniber så meget med ressourcer på kundens server at den ikke kan køre hele tiden.
Vi har haft problematikken forbi NAV gutterne i Kgs. Lyngby helt uformelt, hvor man faktisk allerede var klar over problemet.
Man fik den første gang ifm. en lokal udviklingsklient der skulle tage fat på en Azure Dynamics NAV server. Og oplevede samme problem da det jo pr. definition ikke kører Windows-authentication med mindre de er i samme active domain.
Der er dog desværre ingen aktuelle planer om at ændre på det, så det betragtes med andre ord som en begrænsning “by design”.
Skal der kigges på det igen, så skal de som minimum have en supportsag med et business impact, der viser at ovenstående workaround overhovedet ikke kan anvendes. Men da det er usandsynligt at ovenstående workaround giver reelle problemer, har vi valgt ikke at gøre det. Der er jo vigtigere ting for gutterne i Kgs. Lyngby at tage sig af :-).