klaus_b

Auf den Punkt gebracht: Es spielt keine Rolle welche Konstellation von Back-End und Thin-Client du verwendest. Du bist immer zu langsam. Läut die Anwendung auf dem Back-End und du bekommst nur die Visualisierung auf den Thin-Client ist die Response-Zeit, bedingt durch die Latenz der Verbindung, so im Keller, dass du nicht wirklich Produktiv arbeiten kannst. Läuft die Anwendung auf dem Thin-Client, must du den CLient so hochrüsten, dass es kein Thin-Client per Definition mehr ist. Ja, es muss jedes Pixel einzeln übertragen werden. Ein CAD-System ist keine Visualisierungs-Anwendung, sonder ein hoch interaktives System welches auf jede Aktion des Benutzers sofort reagiert. Hinter jedem Pixel verbergen sich, je nach aktuellem Zoom-Faktor, eine Unmenge von Informationen. Oder wie kann man sonst Elemente manipulieren, deren Disztanz sich beispielsweise im sechsten Nachkommabereich eines Milimeters bewegt? Wenn du diese Anforderungen über eine Netzwerkleitung erfüllen kannst, ohne dabei jedesmal eine Kaffeepause zwischen zwei Aktionen zu erzwingen, spricht nichts gegen die Verwendung einer Server-Client Lösung. Servus, Klaus

Ich bin mir sicher, dass diese "Projekte" reine Verkaufspräsentationen sind :) Nicht wirklich. Der Hersteller der Grafikchips spielt mittlerweile nur noch eine untergeordnete Rolle, da die komplette Visualisierung für fast alle Elemente über OpenGL realisiert wird. Egal ob Linien, Flächen oder Körper. Selbst die Gummiband-Technik bei interaktiver Modellierung wird heute via OpenGL umgesetzt. 256 Mb Grafikspeicher sind ein Witz. 1Gb sollte auf alle Fälle vorhanden sein. Und RAM soviel wie das OS her gibt. Auch die HDs sollten so schnell als Möglich sein. SCSI Ultra 320 ist fast schon Pflicht. Für die CAD-Daten unbedingt eine eigene physikalische Platte verbauen. Unterschätzt die HD-Zugriffe während einer CAD-Session nicht. Ihr dürft euch bei der Arbeit mit CAD-Systemen nicht die Bearbeitung eines einzelnen Bauteils vorstellen, sondern die Bearbeitung ganzer Baugruppen mit zum Teil 5000 und mehr Einzelteilen. Das sind gewaltige Datenmengen, bei denen selbst SCSI Subsysteme beim laden und speichern der Modelle Wartezeiten von 30 sec. bis mehrere Minuten verursachen. Bei der Arbeit mit Baugruppen, werden die einzelnen Bauteile nur visualisiert. Erste wenn eine einzelnen Bauteil zur Bearbeitung selektiert wird, wird dieses real geladen. Wird ein anderes Bauteil ebenfalls zum bearbeiten selektiert, muss diese auch geladen werden. Reicht der RAM nicht, wird geswappt. Oft werden mehrere Modelle parallel in der selben Instanz geöffnet. Beim Wechsel zwischen den verschiedenen Modellen muss das jeweilige als aktiv markiert und in den RAM geladen werden. Wenn ihr die Möglichkeit habt, lasst währen einer CAD-Session den Performance Monitor eine Aufzeichnung von CPU-Last, IO-Zugriffe, RAM-Auslastung und der Pagefile-Auslastung durchführen. Dann werdet ihr schnell sehen, wo der Flaschenhals sitzt. Ich habe die gleiche Diskussion schon öfter mit System ITlern geführt. Erst wenn man ihnen den direkten Vergleich einer "fetten" WS und eines Thin-Client zeigt, haben sie es verstanden. Servus, Klaus

Hallo Thomas, vergiss irgendeine Lösung die nicht auf einer eigenen Workstation beruht. Du kannst gerade CAD und CAM System mit kaum anderen Anwendungen vergleichen. Wenn du ein CAD-System remote anbietest, macht dir das kein Konstrukteur mit. Ich weiß wovon ich rede :) Die Problematik bei CAD-Anwendungen ist die schnelle pixelgenaue Interaktion der Anwendung mit dem Benutzer. Es ist nicht nur so, das du durch die interaktive Modellierung im Raum ein sehr hohes Datenaufkommen zwischen RAM und der Grafik hast, sondern dass jedes sichtbare Element auf dem Bildschirm einen eigenen Kontext bildet. Soll heissen: Wenn der Benutzer die Maus über eine Linie bewegt, bildet die Anwendung einen anderen Kontext, als wenn die Maus über ein Solid (geschlossener räumlicher Körper) oder eine Fläche bewegt wird. Wärend der Mauszeiger in den Geltungsbereich eines Objekts eindringt, werden im Hintergrund bereits die relevanten Daten zum jeweiligen Objekt geladen und beim Maus-Stillstand als Tooltip angezeigt. Während dessen werden im Kontextmenü die objektspezifischen Einträge geladen. Bei übereinander liegenden Objekten muss das dem Benutzer räumlich am nächsten liegende Objekt gewählt und aufbereitet werden. Gleichzeitig eine Auswahlliste der unmittelbar darunter liegenden Objekte erstellt werden. Das waren nur ein paar Beispiel aus einem breiten Reportoar. Wie du siehst gehen während einer CAD-Session eine gewaltige Menge and Daten hin und her. Da kommt nicht einmal eine sehr schnelle LAN-Verbindung mit um in einem erträglichen Maß zu arbeiten. Implementiere statt dessen ein vernünftiges PDM (Product Data Management) dann hast du alle Probleme auf einmal erschlagen: remote Anbindung incl. Authentifizierung Vaulting für vernünftige Teamarbeit Datesicherheit durch Redundanz (beim Check-Out wird eine Kopie der angeforderten Daten auf die WS des jeweiligen User kopiert) Integriertes Backup System Gerade bei CAD-Anwendung solltest du dein IT-Denken umstellen, denn hier gelten ganz andere Anforderungen. Unterhalte dich einmal zwanglos mit einem CAD-Anwender oder Konstrukteur :) Servus, Klaus

Die deutschsprachigen MSDN-Foren sind nicht sehr gut besucht. Als alternative kannst du mal im .NET-Forum.de vorbeischauen.Ich bin mir im MSDN-Forum nicht sicher welches dein Post ist. Ich nehme einfach mal an es war der letzte erstellte vom 19.06.2009 bei dem es um Datenbindung geht. Eines der besten Tutorials zu dem Thema ist die Data Access Tutorials Site auf asp.net. Servus, Klaus

Hallo Mull, In VS ist er jetzt "fest eingebunden". Um den ToolKit in jedem Projekt automatisch zu verwenden, kannst du dir ein ProjektTemplate erstellen. Doch dazu brauchst du erst ein Projekt in dem der ToolKit läuft :) Bevor wir hier wild rumspekulieren, möchte ich dich gerne an das SubForum für den ASP.NET AJAX Control Toolkit auf ASP.NET Forums verweisen. Da lesen auch die Entwickler des ToolKit mit. Ich bin mir sicher, dass dir dort am schnellsten geholfen werden kann. Servus, Klaus

Nicht so schlimm :) Das heist lediglich, dass die dll von VS geladen wird und die Controls als solche erkannt werden. Auch wenn du die Controls jetzt auf deine WebForm ziehen kannst, muss die Assembly der Controls noch in der web.config registriert werden. Da hackt es wars***einlich. Am einfachsten versuchts du einmal eines der Beispiele aus dem ToolKit in VS zu öffnen und mal in VS laufen zu lassen. Wenn das Beispiel läuft, hast du ein Problem mit der Registrierung in der web.config deines Projekts. Schau dir dann die web.config des Beispiel-Projekts an. Befor du ein Beispiel aus dem ToolKit in VS öffnest, kopier es am besten auf eine andere Partition. Aber auf alle Fälle nicht im Program Files Ordner öffnen. Vista mag gar nicht, wenn Anwendungen in den Programme-Ordner schreiben :) Vista != XP :) Servus, Klaus

Hallo mull, Sollte kein Problem sein. Du verwendest also nicht den VS-Developmentserver sondern den IIS von Vista. Mit dem IIS7 benötigst du einige Einstellungen in der web.config. Erstelle einfach ein neues Web-Projekt in VS und vergleiche die web.config des neuen Projekt mit deiner aktuellen. Im untersten Bereich der neuen web.config wirst du einige Änderungen betreffs IIS7 sehen. Du verwendest aber schon die AJAX-Extensions von ASP.NET? Servus, Klaus

Hallo, SQL Express ist keine Trial, sonder ein eigenes Produkt. Falls Du mit "Konsole mit den Datenbanken und Tabellen" das Sql Server Management Studio meinst, so ist das in der Standard Express Version nicht enthalten. Du kannst es hier seperat herunterladen. Falls Du auch die erweiterten Feature, wie etwa Volltextsuche und Reporting, verwenden willst solltest Du die SQL Server 2005 Express Edition with Advanced Services verwenden. Das ist das Management Studio ebenfalls bereits enthalten. BTW: Falls Du die Möglichkeit hast zu wählen, solltest du dich für SQL 2008 Express entscheiden. Sie ist mit den gleiche Features erhältlich wie die Version 2005, allerdings mit allen Neuerungen der Version 2008. Servus, Klaus

Hallo Zahni, natürlich könnte man den Speicherverbrauch begrenzen, sowie diverse andere Kenngrößen. Doch wozu sollte man das tun? Der SQL sollte, entsprechende Datenbankgröße und Nutzerzahlen vorausgesetzt, die einzige Anwendung auf der jeweiligen Box sein. Ich will jetzt bestimmt keine Grundsatzdiskussion vom Zaun brechen :) Servus, Klaus

Guten Morgen Philip, Der SQL-Server lebt vom RAM und verwendet so viel wie er vom OS bekommen kann. Wozu währe denn der RAM sonst da? Der SQL-Server ist mittlerweile fast ein eigenständiges OS, oder zumindest eine sehr komplexe Anwendung mit einer ausgereiften Speicherverwaltung. SQL-Server verwendet den RAM um die oft benötigten Datensätze sowie die entsprechenden Indizes vorzuhalten. Glaube mir, Du willst keinen SQL der die Datensätze erst jedesmal von der Platte liest und nach jeder Transaktion die Daten sofort auf die Platte schreibt und aus dem RAM entfernt. Servus, Klaus

Hallo Markus, nein, nur die .NET Runtime, aber die brauchst Du ja sowieso. Im installationsverzeichnis des .NET Framework, normalerweise unter %SystemRoot%\Microsoft.NET\Framework\[Version]\ findest du die caspol.exe. Um deiner Assembly MagicLibrary z.B.: Fulltrust zu erteile gibst du in einer CommandBox ein: caspol -af MagicLibrary Aber normalerweise macht das der Windows Installer, wenn Du ein Setup-Projekt verwendets. Ohne Setup musst du an die Kommandozeile. Servus, Klaus

Ich kenne das Tool welches Du zum löschen verwendest nicht. Schau mal ob es da einen Parameter gibt um auch versteckte Dateien zu löschen (Attribute H). Wenn nicht verwende in deinem Script das Kommandozeilenprogramm attrib.exe. In etwa attrib -h [dein Dateipfad]\*.tmp Servus, Klaus

Hi SilverDrag0n, Dann scheint eine Betriebssystem-Sperre auf den *.tmp Dateien zu sein. Check mal ob irgend ein Programm noch auf die Dateien zugreift. Mit dem ProcessMonitor von Sysinternals geht das wunderbar. Servus, Klaus

Hallo Andreas, Wofür der Entwickler die Daten der Datenbank braucht verstehe ich nicht. Normalerweise reicht die Datenbank mit ein paar Beispieldatensätzen vollkommen aus. Soll nicht mein Problem sein :D Viellicht kann einer Deiner Entwickler sich ja eine kleine Anwendung "stricken" mit der er mittels der SQL Server API die Datenbank synchronisiert. Damit hatt er ganz andere Möglichkeiten als Du auf der Oberfläche. Für dich hier noch ein paar Infos die die MSDN hergibt: Suche nach: Datenbank kopieren Kopieren von Daten zwischen Servern Vielleicht kommst du ja damit weiter. Servus, Klaus

Hallo Hans. genau dass versucht er ja. Wie Du im ersten Post lesen kannst: hat er auf seinem Laptop die SQL Developer Edition. Wenn Andreas mit dem <Datenbank kopieren> nur auf Probleme stößt, sollte er wirklich die Lösung von Freundlicher in Betracht ziehen. Servus, Klaus

Genau dass sagt doch die Fehlermeldung. Darüber jetzt Mutmaßungen anzustellen bringt nicht wirklich was. Servus, Klaus

Hallo Andreas, Sollte eigentlich gehen. Gehört hier nicht 'Domänenname\Username' hin? Bin mir leider nicht ganz sicher. Servus, Klaus

Hi cjmatsel, .. und warum nimmst du die Datenbank %1 nicht von der Sicherung aus? Servus, Klaus

Hi cjmatsel, Das macht, glaube ich, keinen Sinn und wird Dir sicher nicht helfen Dein Problem zu lösen. Es kann als Administrator nicht Deine Aufgabe sein eine Anwendung, die Release-Status hat, in einer IDE zu debuggen. Freut mich zu hören. Hier gleich noch eine Möglichkeit: Auch der systemeigene Dr. Watson ist ein Debugger, im weiteren Sinn. Wenn Du die ntbackup.pdb in's selbe Verzeichnis legst wie die ntbackup.exe, kann Dr. Watson bei einem Stopfehler die PDB als Symboldatei verwenden um detailierte Informationen, wie etwa die Daten auf dem Stack, auszugeben. Das erspart Dir die komplette installation der Debugging Tools and Symbols. Hier noch ein Link rund um die frei zugänglichen Debugging Tools for Windows. So wie ich das aus Deinem ersten Post herauslese ist Dein Problem jedoch kein Stopfehler, sondern lediglich das Problem dass die Produktiv-DB's nicht mitgesichert werden. Dies kann, muss aber nicht, vorkommen wenn der SQL gerade die DB's sperrt um die aufgelaufenen Transaktionen in die DB's zu schreiben. Statt die aktiven DB's zu sichern, kanns Du auch Backups vom SQL erstellen lassen und diese mit ntbackup auf Band sichern. Hier habe ich noch einen Link für dich, aus der MSDN, über das Sichern und Wiederherstellen von Datenbanken in SQL Server. Dort sollte wirklich jede Deiner Fragen beantwortet werden. Servus, Klaus

Hallo cjmatsel, die PDB's helfen Dir nur etwas wenn Du Visual Studio oder einen anderen Debugger hast, der laufende Prozesse anhängen kann. Angenommen Du hast Visual Studio auf einem Rechner in deinem Netz und ein Konto für das Remote-Debugging auf dem betroffenen Server. Jetzt kopierst Du die PDB-Datei in das gleiche Verzeichnis wie die ntbackup.exe. Visual Studio, oder anderen Debugger, starten und die ntbackup.exe zum debuggen öffnen. Der Debugger ist jetzt in der Lage wirklich sehr detaillierte Informationen über ntbackup.exe auszugeben. Das geht vom simplen überwachen einer Variable zur Laufzeit, bis zum Inhalt eines einzelnen Registers der CPU. Falls es dich interessiert, habe ich hier noch ein paar Links für dich: Debuggen in Visual Studio Debuggen einer ausführbaren Datei, die keiner ..... Hoffe ich konnte Dir die Verwendung einer PDB-Datei etwas näher bringen. Bei deinem eigentlichen Problem lann ich Dir leider nicht helfen, da ich noch nie mit diesem Problem zu tun hatte. Servus, Klaus

Hallo Andreas, Das klingt als würdest Du dich am SQL Server mit Windows-Authentifizierung anmelden, dieser aber SQL Server-Authentifizierung verlangen. Servus, Klaus

Hi Torti, Wenn Du deinen Produktkey echt nicht findest, kannst Du auch den Sql Server Native Client vom SQL 2005 Express installieren, ist der selbe. Servus, Klaus

Bevor Du versuchst den Dienst zu deinstallieren, würde ich erst den Dienst in der Diensteverwaltung auf deaktiviert setzen und dann sehen, Eventlogs udgl., ob irgendwelche Seiteneffekte auftreten (Dienst-Abhängigkeiten). Wenn Du hier keine Probleme feststellt, ist eine Möglichkeit das System in diesem Zustand zu belassen. eine Andere währe: Deine Datenbanken sichern und anschliessend im SSMS (SQL Server Management Studio) die Datenbanken abzuhängen (detach) und auf einen anderen Datenträger kopieren. Dann als erstes den SQL 2000 deinstallieren anschliessend den SQL 2005. Nun solltest Du dein System reinigen (Verzeichnisse und die Registrierung). Nun kannst Du den SQL 2005 neu installieren und hast ein sauberes System. Das ist zwar ein sehr aufwendiger Weg, jedoch auf lange Sicht der bessere. Bedenke bitte, dass der SQL mittlerweile sehr mächtig ist und den Funktionsumfang eines eigenen OS besitzt. Servus, Klaus

Ich vermute mal dass die Upgrade-Routine den Dienst nicht deinstallieren konnte weil er gerade lief, oder dieses gar nicht vorgesehen ist. Eine genau Auskunft kann ich Dir hierzu nicht geben, da ich den SQL nur zu Entwicklungszwecken verwende und statt einem Upgrade lieber die alte Version deinstalliere und die neue sauber installiere. Servus, Klaus

Hy nety, den SQL-Server Dienst-Manager gibt es nicht mehr im SQL 2005. Dafür wurde der SQL Server-Konfigurations-Manager eingeführt. Hier noch ein link zum Thema Migration auf SQL 2005. Vor allem der Updateratgeber für Microsoft SQL Server 2005 dürfte für Dich interessant sein. Servus, Klaus