phoenixcp

Tja, dann solltest du anfangen ein wenig zu üben, wie man noch softer softet. Den afaik gibt es keine Lösung für dein "Problem". Jetzt hängt es also davon, wie du es dem betreffenden verkaufst.

Hast du sie denn auch auf beiden Instanzen ausgeführt? Sonst bringt dich das auch nur nicht weiter. ;)

Tja, ich denke wir könnten den Grund gefunden haben, warum es mal ging und jetzt nicht mehr geht ;) Nix zu danken, dafür ist das Forum doch da.

Dann setz doch mal bitte das folgende Statement auf deine Datenbank ab (ggf. Feldnamen anpassen) Select Count(*) from <Tabelle> where IsNull(IMEI, '') = ''[/Code] Was bekommst du als Result dieser Abfrage zurück? Daraus lässt sich ersehen, wieviele Einträge du aktuell mit einer leeren IMEI in deiner Datenbank hast. Gabs denn ein Applikationsupdate?

Und genau an der Stelle stellt sich die Frage, wer hier die Abprüfung vornimmt. Wenn die Applikation hier eine zusätzliche Abprüfung auf Dubletten vornimmt, können wir an der DB drehen was wir wollen.

Und genau deshalb ist NOT NULL genau die falsche Definition für dieses Feld. DU hast dich aber immer noch nicht zu meiner Frage geäussert: Davon hängt auch ein wenig ab, ob wir da seitens der Datenbank überhaupt noch was machen können ;)

Können könnte man, aber was sollte das bringen? Es handelt sich hierbei dann um einen Primärschlüssel eines Datensatzes. Also auf gut deutsch sowas wie die "einzigartige Adresse" des Datensatzes. Wozu sollte man die ändern? Wenn überhaupt werden die anderen Attribute (Spalten) des Datensatzes geändert.

Was mich grade noch stutzig macht: Welche Software meckert? Die Datenbank oder eine Applikation, welche auf der Datenbank aufsetzt? Da stellen sich den Datenbankern die Nackenhaare auf ;) Man sollte nie ein Datenfeld zu einem PK machen. Ich verwende für soetwas immer ein varchar(38)-Feld, welche über die Funktion NewID() befüllt wird. Dabei erhält mal einen 38-stelligen Wert, den das DBMS zufällig ausrechnet. Mir ist dabei noch keine Dopplung untergekommen. Ein Beispiel (grade frisch erzeugt): D727AC2E-F0E7-482F-9667-9410B0AC75DF[/Code]

Naja, wenn wir uns die Bedeutung der IMEI zu Gemüte führen, wird klar, das er keinen Autowert verwenden kann ;)

Solange wie er schrafiert ist, ist der Termin doch eh lediglich als "Unter Vorbehalt" zu betrachten, da weder eine Zu- noch ein Absage getätigt wurde. Was stört dich denn daran?

U.U. hat die UMTS-Software dir DNS-Servereinträge etc. verbogen.Habe soetwas bei einem Kunden mit griechischer Providersoftware mal gesehen. Ein Blick in die TCP/IP-Einstellungen sowie die Hosts-Datei kann definitiv nicht schaden.

Habt ihr euch denn den 2008er SBS noch garnicht angesehen? Sonst würdest du dir ja deine Frage selber beantworten können. Aber ich denke damit ist die Nachfrage von XP-Fan mehr als ausreichend beantwortet und du solltest ableiten können, was für den Einsatz in Frage kommt.

Ganz ehrlich: hast du was anderes erwartet?

Nein, afaik und soweit die KB das zulässt, gibts da keinen Weg drumrum. Weder Outlook 2k3 / 2k2 noch die entsprechenden CMD-Lets der Ex2k7-Shell sind in der Lage, mehr als 4000 Objekte zu löschen. Allerdings ist die Meldung im entsprechenden KB (Export-Mailbox) etwas missverständlich formuliert: Evtl. gehts ja mit Ol2k7. Test macht schlau. Gruß Carsten

Hallo vip Schau mal hier: Search Results Gruß Carsten

Tja, dann weißt du ja deinen Kreis der Kandidaten, oder? ;)

Also ich würde dir bei deinem Model eine andere Backupstrategie empfehlen: 1 mal täglich Fullbackup der Datenbank mit anschließendem Shrink 4 bis 6 mal täglich Backup des Transaktionslogs mit anschließendem Shrink Nur die DB zu shrinken wird dir nicht viel bringen. Es bringt aus Erfahrung mehr, die Files jeweils einzeln zu shrinken. Das die DB im Bulk-Modus ist, wird seinen Grund haben, also würde ich sie nicht übereilt auf simple umstellen. Evtl. solltest du nach dem einrichten des neuen Wartungsplans für das Transaktionslog darüber nachdenken, ob es nicht sinnvoll wäre, das TRN auf eine Größe einzustellen, bei der es zwischen den Sicherungsintervallen nicht weiter wachsen muss. Allerdings muss man hier dann erstmal sehen wie sich die Größe des TRN einpendelt, wenn es regelmäßig gesichert und geshrinkt wird.

Ok, das Patchset sieht nach meiner Meinung ok aus, ist zwar nicht das aktuellste, aber da steht ja immer noch der SW-Hersteller der DB-Applikation mit davor, bevor man lospatcht. ;) Den freien Speicherplatz in deinem Logfile müsstest du sehen wenn du per Tasks\Shrink\Files das Logfile auswählst. Dort solltest du dann die kleinstmögliche Größe sehen, auf die sich das Transaktionslog shrinken lassen sollte.

JFI: Wäre es nicht "sauberer gewesen", den Client zum Domainmember zu machen?

Wenn der Client Domänenmember wäre, würde es auch nur mit dem Usernamen gehen. ;) Wenn der Client kein Domänenmember ist, brauchst du natürlich noch die Angabe, gegen welche Domäne sich der Client autenthifizieren muss. Gehen würde das dann auch per Domain\User. HTH Carsten

Hallo Tobias Möglicherweise ist schon das Backup, welches du einspielst, korrupt. Versuch mal nach der Wiederherstellung des Servers per SFC.exe /scannow die Systemdateien deines Servers zu checken. Du solltest dabei die Installations-CD bereithalten, falls sich was findet. Einen Test ist auf jeden Fall wert, ebenso ein ausgiebiges chkdsk, um zu sehen ob die Platte(n) einen weg haben. Gruß Carsten

Wieviel freier Platz ist denn in dem Transaktionslog vorhanden? In welchem Recovery Mode steht denn die Datenbank? Full, Bulk oder Simple? Ich glaube zwar die Antwort zu kennen, aber wer weiß. Welchen Patchstand hast du auf deinem SQL Server installiert? Die kannst du mit select @@version[/Code] checken.

Hallo Hans Hast du nach dem erneuten Setzen der Größe des Transaktionsprotokolls das Logfile erneut gesichert und verkleinert? Gruß Carsten

Hallo Wallace Von welchem EMail-Client aus versuchst du dich anzumelden? Ist der Client ein Domänenmember oder nicht? Ich denke nicht, das das am SP liegt. ;) Gruß Carsten

Ich denke das hängt ganz von dem Vertrag mit dem Dienstleister ab. Und ab dieser Stelle wird es Rechtsberatung welche wir hier weder leisten können (mangelndes fachliches Knowhow) noch wollen. Dazu wendest du dich am besten an den Rechtsbeistand deines Vertrauens. Vielen Dank für dein Verständnis. Gruß Carsten