As some of you may have noticed, this blog was not reachable for the last couple of days.

This was caused by some bigger server-problems.

I moved the blog now to a more stable server and used this possibility to change the blogs url to http://blog.dfugel.de

The old url is still valid but will be removed in a few months, so please change the URL of your rss-reader.

Durch einige Serverprobleme war das Blog leider für mehrere Tage nicht mehr erreichbar.

Um dies in Zukunft zu vermeiden wurde das Blog nun auf einen anderen Server umgezogen.

Ich habe diese Gelegenheit gleich dazu genutzt auf eine neue URL umzustellen: http://blog.dfugel.de

Bitte denkt daran eure vorhandenen RSS-Feeds umzustellen.

Die Convergence 2012 ist vorbei und die ersten Informationen sind bereits durchgesickert.

Hier ist etwas, dass ich bis jetzt noch niergends gelesen habe:

The beta release for Microsoft Dynamics NAV 2013 is expected in May 2012.

Was sagt dieses Zitat nun aus

Zum einen: Microsoft Dynamics NAV ‘7’ wird Microsoft Dynamics NAV 2013 heissen.

Zum zweiten: Wir dürfen mit der BETA-Version in den nächsten Wochen rechnen.

Dieses Zitat stammt aus dem Microsoft News Center:

http://www.microsoft.com/Presspass/press/2012/mar12/03-19Convergence2012PR.mspx

The Convergence 2012 is over and some new information already leaked out to the mass.

Here is one thing I didn’t already read in other blogs:

The beta release for Microsoft Dynamics NAV 2013 is expected in May 2012.

But what does this quote tells us?

First of all: Microsoft Dynamics NAV ‘7’ will be called Dynamics NAV 2013.

Secondly: The Beta could be availabale in some weeks.

The quote is taken from Microsoft News Center:

http://www.microsoft.com/Presspass/press/2012/mar12/03-19Convergence2012PR.mspx

Ich habe heute etwas neues gelernt, an dem ich euch gerne teilhaben lasse:

Bedingt durch die Netzwerkarchitkektur, kann es passieren, dass man sich auf einen Server remote verbinden muss, nur um von dort eine weitere RDP-Verbindung zu seinem anderen Server zu öffnen.

Oder in kurz: Man verbindet sich von seinem PC zu Server A. Von Server A verbindet man auf Server B.

Während einer RemoteDesktop-Verbindung ist es möglich seinen lokalen Laufwerke (also die am PC) mit dem Remote-Computer (Server A) zu teilen. Man hat also Zugriff auf die Laufwerke von PC von Server A aus. Diese Laufwerke können allerdings nicht bis zu Server B durch geschliffen werden.

Es gibt aber einen einfachen Trick um die lokalen Laufwerke auf Server B zu bekommen. Man kann die freigegeben Laufwerke auf Server A als Netzlaufwerk verbinden. Diese werden dann an Server B freigegeben. (z.B. der Pfad für Laufwerk C):

\\tsclient\c

Du kennst weitere Tipps und Tricks zu RempteDesktopVerbindungen? Dann nutze die Kommentarfunktion um uns daran teilhaben zu lassen.

Today I learned something new, which I would like to share with you:

It could happen, that caused by network-structure and security-rules you are forced to remote-connect to a server just to open a remote-connection to another machine from this server.

Or in Short: You sit in front of your PC and remote-connect to Server A. From Server A you open a remote-connection to Server B.

When you share your drives during remote-connection, you local drives (from PC) are available at Server A, and the drives of Server A are available on Server B. But your local drives (from PC) are not available on Server B.

There is some easy way to get direct access to your local drives from Server B. You can map the PC-drives on Server A as network-drives. You only have to use this networkpath (i.e. for drive c):

\\tsclient\c

You have other interessting tricks for RDP-Connections? Just use the comment-function to let us know.

Da die Frage heute erneut aufkam, würde ich gerne kurz etwas zum Object Change Listener erzählen.

Seit dem Release von Microsoft Dynamics NAV 2009 gibt es nicht mehr die klassische Client/Server-Umgebung. Mit 2009 wurde der neue Rollenbasierte Client (RTC = Role Tailored Client) eingeführt. Dieser ist nur noch für die Anzeige der Daten zuständig, sämtliche Logik wird auf dem neuen Dienst Service Tier ausgeführt.

Wenn man nun in einer NAV 2009 Datenbank entwickelt kann es passieren, dass die Änderungen nicht im RTC auftauchen. Für Entwickler die auch schon in früheren Versionen mit mehrern Clients auf eienr Datenbank entwickelt haben ist dies vermutlich nichts Neues, allerdings hilft in diesem Fall der Neustart des Clients nicht weiter. Dadurch, dass wir nun das ServiceTier zwischen der Datenbank und dem RTC haben, ist ein Neustart des ServiceTiers notwendig.

Da es im Normalfall allerdings nur ein ServiceTier für mehrere Anwender gibt, sollte man dies nicht zu oft machen.

Natürlich ist sich Microsoft darüber im klaren und bietet mit dem Object Change Listener eine einfache Lösung hierfür an.

Besagter Object Change Listener tut nicht mehr und nicht weniger als die Objekte der Datenbank auf Änderungen hin zu überwachen. Wird ein Objekt geändert, so veranlasst er das ServiceTier sich das Objekt neu aus der Datenbank zu laden, anstatt das gecachte Objekt an den RTC zu übergeben.

Wann man diesen selbst einrichten muss und wie das funktioniert ist kurz und knackig in diesem MSDN-Beitrag beschrieben:

MSDN-Article: Activate Object Change Listener

Wenn man wissen möchte ob auf der aktuellen Datenbank der broker aktiviert ist, kann man dies in der sys.databases-Tabelle des SQL-Servers nachschauen. Dort gibt es das Feld is_broker_enabled, welches den aktuellen Status anzeigt (0 = aus, 1= ein).

Since the question just poped up I would like to say something about Object Change Listener.

If you are developing within Microsoft Dynamics NAV 2009 (SP1 / R2) you have the possibility to use the new RoleTailoredClient (RTC). This RTC does not execute buisines logic anymore. The buisines logic is executet on the ServiceTier, a new service which came with NAV 2009.

When you develop objects within NAV 2009 and want to see them in RTC it can happen that your changes are not available. This is nothing new if you had more then one client developing in yout database before. But with RTC it does not solve the problem to restart your client. This is caused by the new architecture. Since the objects are called from servicetier you have to restart the servicetier instead.

Since in most cases there is only one servicetier for multiple RTClients, you do not want to do this to often.

Of course Microsoft knows about this and provides the object change listener to solve the problem.

The object change listener does no more but to watch the objects within the database and cause the servicetier to fetch the newest version of an object if it was changed.

There is an article available at MSDN how to enable the object change listener.

MSDN-Article: Activate Object Change Listener

If you want to know wether your Object Change Listener is activated for the current database you could have a look at the sys.databases-table. There is a field called is_broker_enabled which tells you the current status.