<?xml version="1.0" encoding="utf-8"?>
<sage50_rewe_configuration>
	<dbms>
		<default_dbms_type>SqlServer</default_dbms_type>
		<dbms_configurations>
			<dbms_configuration dbms_type="SqlServer">
				<server_name>(local)</server_name>
				<instance_name>SESAM</instance_name>
				<user_name>Master</user_name>
				<password>sesam</password>
			</dbms_configuration>
		</dbms_configurations>
		<!--
      Falls der Client eine Zeit lang inaktiv ist und keine Zugriffe auf das
      DBMS macht, wird vor dem nächsten Zugriff geprüft, ob die Verbindung zum
      DBMS noch aktiv ist. Falls die Verbindung abgebrochen ist wird sie wieder
      aufgebaut. Diese Einstellung legt fest, wieviele Sekunden maximal zwischen
      zwei DBMS-Zugriffen verstreichen darf, bevor der Verbindungs-Check gemacht
      wird.
      Default-Wert = 1800 Sekunden (= 30 Minuten)
    -->
		<connection_check_after_inactivity_period_in_seconds>1800</connection_check_after_inactivity_period_in_seconds>
		<!--
      Legt fest, wie lange eine SQL Query maximal dauern darf, bevor sie wegen
      eines Timeouts abgebrochen wird. Wert 0 = Kein Timeout. Der ADO.NET
      Default ist 30 Sekunden. Das ist zu kurz für massive Queries wie sie z.B.
      bei der Berechnung von Kennzahlen bei Mandanten mit sehr vielen Buchungen
      auftreten.
      Default-Wert = 300 Sekunden (= 5 Minuten)
    -->
		<command_timeout_in_seconds>300</command_timeout_in_seconds>
	</dbms>
	<dal>
		<locking>
			<pessimistic_offline_locking>
				<!--
          Legt fest, wie lange der Client maximal auf ein Lock warten darf,
          bevor der Versuch, das Lock zu erhalten, abgebrochen wird. Diese
          Einstellung wird nur bei denjenigen Lock-Mechanismen berücksichtigt,
          bei denen Timeouts überhaupt zum Einsatz kommt. Beispiel: Es darf
          immer nur 1 Client zur gleichen Zeit Belege erstellen (egal ob manuell
          durch den Benutzer in einer Buchungsmaske, automatisch via
          TAF/CSV-Import oder programmatisch via FibuSDK).
          Wert 0 = Kein Timeout. ACHTUNG: Dieser Wert darf nicht zu klein
          eingestellt werden, da sonst Clients schon bei kurzen Verzögerungen
          im Netzwerk ihre angeforderten Locks nicht mehr erhalten. Falls sich
          Lock-Wartezeiten tatsächlich bemerkbar machen ist das Grundproblem
          meistens nicht das Locking an sich, sondern muss an anderer Stelle
          gesucht werden (z.B. ausgelasteter DB-Server).
          Default-Wert = 300000 Millisekunden (= 5 Minuten)
        -->
				<lock_timeout_in_milliseconds>300000</lock_timeout_in_milliseconds>
				<!--
          Nachdem ein Client ein Lock angefordert und erfolgreich erhalten hat
          fährt der Client normalerweise sofort mit der Programmausführung fort.
          Hier kann eine künstliche Verzögerung festgelegt werden: Der Client
          wartet dann jedesmal, nachdem er ein Lock erhalten hat, solange wie
          hier angegeben. Wert 0 = Keine Wartezeit. ACHTUNG: Diese Einstellung
          dient lediglich dem Simulieren von Lock-Wartezeiten zu Test-Zwecken
          und sollte in einer produktiven Umgebung IMMER den Wert 0 haben!
          Default-Wert = 0 Millisekunden
        -->
				<delay_after_lock_was_obtained_in_milliseconds>0</delay_after_lock_was_obtained_in_milliseconds>
			</pessimistic_offline_locking>
			<optimistic_offline_locking>
				<!--
          Optimistisches Offline Locking (OOL) dient dazu, Dateninkonsistenz
          beim Schreiben ein und des gleichen Datensatzes durch mehrere Clients
          zu verhindern. Client 1+2 laden beide den gleichen Datensatz. Client 1
          schreibt seine Änderung zuerst, Client 2 schreibt seine Änderung erst
          danach. Ohne OOL überschreibt Client 2 die Änderung von Client 1. Mit
          OOL schlägt das Schreiben von Client 2 fehl. Mit der vorliegenden
          Option kann OOL für den Btrieve Wrapper abgeschaltet werden. Die
          Option existiert lediglich für den Notfall und sollte eigentlich nie
          verwendet werden (d.h. OOL sollte auch für den Btrieve Wrapper immer
          eingeschaltet bleiben). In einer zukünftigen Version von Sage 50 wird
          die Option unter Umständen wieder entfernt werden.
          Default-Wert = true
        -->
				<enabled_for_btrieve_wrapper>true</enabled_for_btrieve_wrapper>
			</optimistic_offline_locking>
		</locking>
	</dal>
	<default_clients>
		<restore_on_startup>true</restore_on_startup>
	</default_clients>
</sage50_rewe_configuration>
