| T H E M A Ü B E R S I C H T |
| herrmanj |
Gesendet - 21/08/2018 : 10:23:42
Ich weiß nicht, ob es ein wirkliches Problem ist, aber komisch ist es schon und besser es wurde gemeldet als wenn das Problem dann akut wird. Mitunter interessiert so etwas auch die Softwareentwickler. Ich hatte jetzt schon 3x ohne Grund Sprünge um jeweils ca. 1000 Stellen in meinen Rezeptnummern in der Datenbank.
Jan H. |
| 14 L E T Z T E A N T W O R T E N (Die neueste zuerst) |
| herrmanj |
Gesendet - 24/08/2018 : 12:15:38
Ich habe mich mal in den Stoff etwas reingelesen und denke die Lösung mit den Trace Flags wird dem normalen Anwender (so wie ich) etwas zu kompliziert sein.
Es ist ja gut zu wissen, dass es eine Lösung gibt, aber wenn ich sie nicht anwenden kann, ist es in dem Sinne für den Nutzer eben doch irgendwie keine Lösung.
Ich sehe 3 Möglichkeiten wie es weiter gehen könnte:
1. Es bleibt alle wie es ist.
2. RD findet eine Lösung auf der adad95-Seite.
3. RD schreibt eine Hantierungsanweisung, was genau bei der SQL-DB mit "trace flag 272" zu machen ist.
Ich würde mich über 2. freuen und wäre über 3. nicht böse. |
| herrmanj |
Gesendet - 24/08/2018 : 12:03:13
Zitat:
Ersterfassung durch Entwicklung
Ja, es gibt auch eine SQL – Server Einstellung die das Springen der ID’s nach Neustart des Servers zukünftig verhindert. Siehe Trace Flag 272
https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql?view=sql-server-2017
Hier noch mal der Link für Forenmitglieder die des angelsächsischen nicht so mächtig sind
https://docs.microsoft.com/de-de/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql?view=sql-server-2017 |
| mechanicus |
Gesendet - 22/08/2018 : 16:50:29
Das versteht doch nun hier wirklich keiner mehr.
Warum beheben Sie den Fehler nicht einfach mit Ihrem Trace Flag statt hier zu argumentieren, der Fehler wäre kein Fehler und wenn, dann nicht so schlimm.
|
| Entwicklung |
Gesendet - 22/08/2018 : 16:02:26
Sie sagen, das Setzen des Trace Flag ist keine Lösung.
Ich sage, diese Behauptung ist falsch, das Setzten des Trace Flags ist die Lösung wenn man denn den SQL Server veranlassen will die Nummern (ID's) ohne Lücken zu vergeben.
Wo ist da die Wortklauberei
|
| mechanicus |
Gesendet - 22/08/2018 : 15:52:34
Zitat:
Entwicklung Zitat:
mechanicus gesendet - 22/08/2018 : 14:34:24
Das mit dem Trace Flag hatten Sie doch geschrieben:
Richtig und Sie hatten dann geschrieben: Das ist keine Lösung! Diese Behauptung ist faktisch falsch.
Siehe Post vom - 21/08/2018 : 13:39:01
Mein verstorbener Vater nannte so was Wortklauberei.  |
| Entwicklung |
Gesendet - 22/08/2018 : 15:13:28
Zitat:
Es bleibt doch ein Fakt, dass jedes abgerechnet Rezept als Einnahme zu buchen ist. Wenn nun anhand der Rezeptnummern in einem Zeitraum mehr Rezepte vermutet werden können, als gebucht wurden, ist das zumindest erklärungsbedürftig.
1. Man bucht bezahlte Rechnungen und keine Rezepte.
2. Aber wohl eher vom freundlichen Finanzbeamten als vom Praxisinhaber. Die Begründung da ist eine Lücke in der Nummerierung von Rezepten wird ja wohl nicht reichen. Denn es steht nirgendwo die Nummerierung muss lückenlos aufsteigend sein
Zitat:
mechanicus Gesendet - 22/08/2018 : 14:34:24
Das mit dem Trace Flag hatten Sie doch geschrieben:
Richtig und Sie hatten dann geschrieben: Das ist keine Lösung! Diese Behauptung ist faktisch falsch.
Siehe Post vom - 21/08/2018 : 13:39:01
|
| mechanicus |
Gesendet - 22/08/2018 : 14:34:24
Zitat:
Entwicklung Die Realität ist, es gibt keine Verpflichtung Rezepte zu nummerieren und die Behauptung die nicht vorgeschriebene Nummerierung müsste lückenlos aufsteigend sein, ist frei erfunden.
Es bleibt doch ein Fakt, dass jedes abgerechnet Rezept als Einnahme zu buchen ist. Wenn nun anhand der Rezeptnummern in einem Zeitraum mehr Rezepte vermutet werden können, als gebucht wurden, ist das zumindest erklärungsbedürftig.Zitat:
Entwicklung Ein einfacher Betriebsprüfer des Finanzamtes hat in diesem Teil der Praxissoftware nix zu suchen und ist froh, wenn er die exportierte Buchhaltung auf seinem dienstlichen Rechner prüfen kann.
Völlig richtig. Nur braucht es zum Nachweis einfach nur der Rechnungen, weil auf diesen ja die Rezeptnummern vermerkt sind.Zitat:
Entwicklung @mechanicus Nicht nur einfach behaupten Rezepte müssten lückenlos Nummeriert werden, sondern die Vorschrift benennen.
Wo habe ich das behauptet?  Ich habe nur geschrieben, dass es bei den beschriebenen Sprüngen zu Erklärungsnotwendigkeiten kommen kann, was ja wohl nicht im Ernst bestritten wird?Zitat:
Entwicklung Bei der Behauptung das Setzen des Trace – Flags wäre keine Lösung wurde nicht wirklich nachgelesen sondern einfach der obere allgemeine Hinweis genommen.
Das mit dem Trace Flag hatten Sie doch geschrieben:
Zitat:
Ja, es gibt auch eine SQL – Server Einstellung (...) Siehe Trace Flag 272
|
| Entwicklung |
Gesendet - 22/08/2018 : 12:23:58
Die Realität ist, es gibt keine Verpflichtung Rezepte zu nummerieren und die Behauptung die nicht vorgeschriebene Nummerierung müsste lückenlos aufsteigend sein, ist frei erfunden.
Um das Ganze dann noch dramatischer zu machen, kommt der böse Finanzbeamte und rechnet anhand der von fehlenden Nummern irgendwelche nicht vorhandenen Umsätze aus. Ein einfacher Betriebsprüfer des Finanzamtes hat in diesem Teil der Praxissoftware nix zu suchen und ist froh, wenn er die exportierte Buchhaltung auf seinem dienstlichen Rechner prüfen kann.
@mechanicus Nicht nur einfach behaupten Rezepte müssten lückenlos Nummeriert werden, sondern die Vorschrift benennen.
Zum eigentlichem Problem.
Bestimmte Versionen des MS – SQL Servers haben die Eigenart nach einem unerwarteten Neustart. Da springt auch nix hin und her es geht nur nach oben. Das Verhalten, sagt man, hat mit der immer wichtiger werdenden Geschwindigkeit zu tun.
Bei der Behauptung das Setzen des Trace – Flags wäre keine Lösung wurde nicht wirklich nachgelesen sondern einfach der obere allgemeine Hinweis genommen. Liest man bei dem speziellen Flag nach, so sieht man, dass beginnend mit der MS – SQL Server Version 2017 ein Ersatz, unter anderem, für dieses Flag eingebaut wurde.
Man kann also davon ausgehen, dass bei einer zukünftigen Version statt dem Flag nur noch die ‘ ALTER DATABASE SCOPED CONFIGURATION‘ funktioniert wird. Erfahrungsgemäß funktionieren beide Methoden jedoch einige Versionen parallel.
Die vorgeschlagenen programmtechnischen Lösungen funktionieren so sicher nicht. Autowert – Spalten sind immer schreibgeschützt und werden ohne Zutun bei Neuanlage des Datensatzes vom System vergeben.
@Hand und Herz. Für die Vergabe von Rechnungsnummern und Belegnummern wird nicht die hier diskutierte Funktion des MS – SQL Servers genutzt. Somit sind diese Nummern auch nicht betroffen.
|
| Hand und Herz |
Gesendet - 22/08/2018 : 11:26:43
"Das wäre eine Lösung mit Trace Flags,
aber:
Zitat:Microsoft: (!) Important
Trace flag behavior may not be supported in future releases of SQL Server.
Also keine Lösung!"
Was ist denn nun die Lösung, damit wir alle bei einer Buchführung uns auf das Programm verlassen können? |
| mechanicus |
Gesendet - 21/08/2018 : 20:44:17
Zitat:
Entwicklung: Wenn wirklich die Sorge besteht, sollte man einfach die Rezeptnummern in der Rezeptliste ausblenden.
Ah ja, wenn die Realität nicht passt, schließt man einfach die Augen ...
Ich bin zwar (noch) nicht betroffen, aber die Art, wie Sie die Probleme kommunizieren, ist schon bemerkenswert.
Was spricht denn dagegen, den Fehler mit wenig Aufwand abzustellen?
Eine Lösung wäre z.B., bei jeder Rezeptneuanlage abzufragen, ob der Zähler konsistent ist. Wenn nicht, wird einfach um Tausend reduziert. |
| Entwicklung |
Gesendet - 21/08/2018 : 14:21:08
Seit wann müssen Rezepte eindeutige Nummern haben und dürfen nicht gelöscht werden. Für die Abrechnung werden nur eindeutige Rezept- Nummern innerhalb der einen Rechnung benötigt.
Wenn wirklich die Sorge besteht, sollte man einfach die Rezeptnummern in der Rezeptliste ausblenden.
Rechnungsnummern werden anders verwaltet und können aus dem Grund Sprünge dieser Art nicht aufweisen.
|
| mechanicus |
Gesendet - 21/08/2018 : 13:39:01
Zitat:
Entwicklung: Das Verhalten ist bekannt und Microsoft ist der Meinung das ist so richtig.
Toll, mal wieder typisch für Microsoft. Die beste aller Datenbanken! Was springt denn sonst noch so im Datenbestand hin und her? Zitat:
Entwicklung: Da wir derzeit 2.147.483.648 mögliche Rezeptnummern vergeben können sehe ich die Sprünge auch entspannt.
Aus dem weiter oben von mir genannten Grund sehe ich das nicht so entspannt.
Bei herrmanj könnte das dann so aussehen, dass bei einem Rezeptdurchschnittswert von 100 € 3x1000x100 = 300.000 € Umsatz hinzugeschätzt würden, weil eine Löschung unterstellt wird. Das könnte natürlich mit viel Erklärungsaufwand entkräftet werden, aber wenn man an einen Prüfer kommt, der seine Statistik schönen will, ...
Zitat:
Entwicklung: Ja, es gibt auch eine SQL – Server Einstellung die das Springen der ID’s nach Neustart des Servers zukünftig verhindert. Siehe Trace Flag 272
Das wäre eine Lösung mit Trace Flags,
aber:Zitat:
Microsoft: (!) Important
Trace flag behavior may not be supported in future releases of SQL Server.
Also keine Lösung!
|
| Entwicklung |
Gesendet - 21/08/2018 : 12:10:10
Die Sprünge entstehen nach dem Neustart des SQL – Servers. Das Verhalten ist bekannt und Microsoft ist der Meinung das ist so richtig. Da wir derzeit 2.147.483.648 mögliche Rezeptnummern vergeben können sehe ich die Sprünge auch entspannt.
https://social.msdn.microsoft.com/Forums/sqlserver/de-DE/ed0f5eb9-1aaf-4ece-ad86-793e9d16ef79/autoincrement-id-springt-von-1-auf-1000?forum=sqlserverexpressde
und
https://docs.microsoft.com/de-de/sql/t-sql/statements/create-table-transact-sql-identity-property?view=sql-server-2017
Siehe Aufeinanderfolgende Werte nach Serverneustart oder anderen Fehlern
Ja, es gibt auch eine SQL – Server Einstellung die das Springen der ID’s nach Neustart des Servers zukünftig verhindert. Siehe Trace Flag 272
https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql?view=sql-server-2017
|
| mechanicus |
Gesendet - 21/08/2018 : 11:45:35
Sehr seltsam, zumal es nur in der 1057 (ab 05.04.2018) auftaucht.
Ich habe das bei mir mal überprüft und kann das nicht bestätigen.
Ich kann Dir nur raten, das mit dem Rezeptdatum zusammen genau zu dokumentieren und nicht zu löschen, weil ansonsten das Finanzamt bei einer Betriebsprüfung dazuschätzen wird.
Dann hättest Du Dein "wirkliches Problem".  |
