ich bin gerade dabei ein Projekt von MS Sync Framework 1 auf das aktuelle 2.1 umzustellen. Dabei möchte ich auch das ganze Synctabellen, Trigger und Stored Procedure Zeug los werden und das Change Tracking das SQL Servers 2008 nutzen. Von dem ich mir mehr Übersicht in der Datenbank (weil nicht zu jeder Tabelle noch extra Tabellen angelegt werden müssen) und mehr Performance (weil nicht mehr über Trigger und Stored Procedures behandelt) erhoffe.
In der Version 2.0 des Sync Frameworks musste man hierfür eine DbServerSyncProvider nehmen und die SQL Statements auf das Change Tracking des SQL Servers anpassen. Das Filtern erfolgte dann in abgeleiteten SyncAdaptern in denen man ebenfalls die SQL Statements anpassen musste.
Beim lesen der Hilfe für die Version 2.1 habe ich gesehen, dass in Verbindung mit dem SqlSyncProvider die Möglichkeit gibt Zeilen und Spaltenfilter schöner zu definieren als durch das anpassen des SyncAdapters. Was ich aber aus der Hilfe nicht eindeutig rauslesen konnte, war ob der SqlSyncProvider nun das ChangeTracking des SQL Servers unterstützt. Dies war in der Version 2.0 noch nicht der Fall.
Hat hier vielleicht schon jemand Erfahung mit der Version 2.1?
Hi,
ich habe ein UserControl erstellt auf dem ein GridView und eine ObjectDataSource
liegen. Diese bekommen über eine Eigenschaften die Information welche Daten angezeigt werden sollen. Das UserControl bietet eine Update Methode welche das Query ausführt und anschließen ein Changed Event des UserControls auslößt.
Die Daten werden in das GridView geladen und der erste Datensatz wird selektiert. Die DataKeyNames Eigenschaft des GridViews ist auf den Primärschlüssel des Datensatzes gesetzt und wird über eine Eigenschaft direkt wieder an die Seite zurück geben.
public int SelectedData
{
get
{
int data = 0;
if (GridView1.SelectedPersistedDataKey != null)
{
data = (int) GridView1.SelectedPersistedDataKey.Value;
}
return data;
}
}
Die Parameter für dieses UserControl werden über eine andere GridView ausgewählt und an das UserControl in der SelectedIndexChanged Methode übertragen.
Das ganze funktioniert beim ersten Pageload (IsPostBack = false)
und wenn ich die Daten im GridView des UserControls per Maus selektiere. Dann wird das SelectedChangedEvent des UserControls gefeuert und die Seite bekommt über die SelectedData Eigenschaft den richtigen Wert geliefert.
Wenn ich jedoch einen anderen Parameter für das UserControl in dem GridView der Seite wähle wird zwar das GridView im UserControl aktualisiert und zeigt die richtige Datan an aber die SelectedData Eigenschaft liefert noch den zuletzt selektierten Wert zurück und noch nicht den neuen, welcher jedoch bereits im UserControl als selektiert dargestellt wird.
kann denn eine Verbindung mit dem Server hergestellt werden?
Mal ein Ping versucht bzw. eine Verbindung mit einem anderen Client
(HeidiSql, Database Brower, etc) versucht?
Und wo ich mir das grad nochmal durchlese:
Bist du dir sicher, dass man mit der SqlConnection sich mit einem MySQL Server
verbinden kann?
Ich habe dafür immer den ADO.NET Adapter von MySQL verwendet. Damit gab es nie Probleme.
Ergebnis war, dass er nach der Weiterleitung das Cookie findet und Abmelden anzeigt aber sobald ich auf eine andere Seite navigiert habe wurde wieder Anmelden anzeigt.
Hatte erst gedacht es wäre ein Problem mit der Gültigkeitsdauer und habe das Cookie auf 30 Min gesetzt, dass hatte aber keine Auswirkung.
ich habe einen eigenen MembershipProvider erstellt um Benutzer gegen
meine Datenbank authentifizieren zu können.
Ich habe ihn bis jetzt als Quelle für die BasicAuth meines WebServices verwendet.
Nun möchte ich ihn auch für die FormsAuthentication verwenden, hier gibts aber noch Probleme.
Ich hab eine LoginPage mit dem LoginControl erstellt, in der Membership Property meinen Membership Provider
gesetzt und in den Master ein LoginStatus gepackt um zu sehen ob es geklappt hat.
Wenn ich mich nun über die Login Seite anmelden will werden Benutzername und Passwort über meinen MembershipProvider geprüft und dieser liefert TRUE zurück.
Ich werde weitergeleitet auf die Default.aspx aber der Loginstatus zeigt noch anmelden.
Versuche haben gezeigt, dass auch Context.User.Identity.IsAuthenticated False zurück liefert und der Context.User.Name == "" ist.
Hat jemand eine Idee woran das liegen kann?
Hab ich irgendwo etwas vergessen?
soweit ich weiß ist das CF recht eingeschränkt was die Gestalltung
der grafischen Komponenten angeht, das viele der Funktionen welche
die WM API bereitstellt nicht implementiert sind.
Du kannst also entweder den Button ableiten und die fehlenen Funktionen
nach implementieren oder dir direkt einen eingen Wrapper um die WM API
machen. Wir haben bei unseren Anwendungen die letztere Methode gewählt.
Generell gebe ich dir recht in echten Anwedungen sollte man mit Events arbeiten..
das oben war auch nur ein Beispiel zum nachvollziehen.
Das Problem ist durch Events aber nicht gelößt.. da es kein Event gibt das einem meldet, dass etwas gesendet wurde und sich das Senden damit auch nicht forcieren lässt. Und das Hauptproblem nicht ist, dass ich ein Timeout beim empfangen bekommen,
sondern dass das Zeichen erst garnicht rausgesendet wird. Problem scheint bei XP zu sein, dass erst ab mehr als einem Zeichen im Puffer gesendet wird.
Habe mir jetzt mit dem Hack beholfen die WriteBufferSize auf 1 zu setzen, beim Öffnen abzuprüfen, ob die Verbindung offen ist und wenn ja die Exception zu unterdrücken. Und anstatt
serialConnection.Write("V");
verwende ich
serialPort.Write(new char[] { 'V' },0 ,1);
in dieser Kombination läuft das Übertragen von einzelnen Zeichen sowohl unter XP als auch auf Win7.
ich versuche gerade mit .net 2.0 und SerialPort eine serielle Kommunikation aufzubauen und bin dabei unter XP auf folgendes Problem gestoßen, welches auf meinem Win7 Rechner erst garnicht auftritt:
serialPort.Write("V");
char c = (char)serialPort.ReadChar(); // read echo
wirft ReadChar ein Timeout weil Write das Zeichen wohl noch nicht gesendet hat.
Bisher hab ich versucht dazwischen ein
serialPort.BaseSteam.Flush();
oder ein
Thread.Sleep(time);
aufzurufen beides ohne Erfolg. Der Writebuffer wird nicht übertragen.
Dabei den versuchen habe ich noch ein sehr Merkwürdige verhalten entdeckt:
wenn man
serialPort.WriteBufferSize = 1;
setzt bekommt man beim Open() eine Exception, dass der Port nicht geöffnet werden kann. serialPort.IsOpen meldet aber true. Und man kann danach auch senden und empfangen. Und da der Puffer nach einem Zeichen voll ist wird er auch übertragen. Seitzt man die WriteBufferSize = 2 tritt beim Open() keine Exception auf jedoch wird dann auch das einzelne Zeichen nicht mehr gesendet.
Das lustige an der Geschiche: MSDN sagt zu WriteBufferSize Werte unter 2048 werden ignoriert...
Möchte also nicht unbedingt die Exception wegfangen und drauf hoffen das dieser "Fehler" auf jedem System funktioniert.
Gibt es eine Möglichkeit ein Zeichen sicher abzusenden, welche sowohl unter XP als auch Win7 funktioniert?
ich habe das ExtendedFileDialog von codeproject verwendet und hab unter Win7 x64 das Problem, dass die Events nicht feuern. So wie es aussieht geht beim Hook der die WMs
verarbeitet etwas schief. Hat das vielleicht schon jemand gelößt?
Also mein jetziger Ansatz wäre es einen Brush abzuleiten und den Farbverlauf selbst zu berechnen als ähnlich wie man dann dann bei 3.0 machen würde über kleine Integrationsschrittweite ..
Prinzipiell dürfe das schon möglich sein.. ich denke aber das der Zählerstand eine Sache des Herstellers ist und du schauen musst, wie du über dessen Treiber API die Werte bekommst.
Also ohne genauere Info über die Geräte werden wir dir nicht viel weiter helfen können.
WSE hat ab Version 2.0 ein integrierten Schutz vor DoS Attacken..
Blöd wenn er den eigenen Datentransfer auch als DoS erkennt aber die Exception nicht nach außen weiter gibt...
mit dem app.config Eintrag
<maxMessageLength value="1024" />
lässt sich die zugelassene Datenmenge angeben. Mit -1 wird der DoS Schutz deaktiviert.
Hab das ganze jetzt mal auf SoapMethod und SoapClient umgebaut und bekomme jetzt zumindest ein Timeout und das Logging auf der Serviceseite liefert eine Fehlermeldung:
<faultcode>soap:Server</faultcode>
<faultstring>System.Web.Services.Protocols.SoapHeaderException: Server unavailable, please try later ---> System.IO.IOException: WSE2150: Write Failure. ---> System.Net.Sockets.SocketException: Eine vorhandene Verbindung wurde vom Remotehost geschlossen
bei System.Net.Sockets.Socket.EndSend(IAsyncResult asyncResult)
bei Microsoft.Web.Services3.Messaging.SoapTcpNetworkStream.EndWrite(IAsyncResult asyncResult)
--- Ende der internen Ausnahmestapelüberwachung ---
bei Microsoft.Web.Services3.Messaging.SoapTcpNetworkStream.EndWrite(IAsyncResult asyncResult)
bei Microsoft.Web.Services3.Messaging.SoapTcpNetworkStream.Write(Byte[] buffer, Int32 offset, Int32 count)
bei System.IO.Stream.WriteByte(Byte value)
bei Microsoft.Web.Services3.Messaging.Framing.FramingRecord.WritePadding(Stream stream, Int32 bytesWritten)
bei Microsoft.Web.Services3.Messaging.Framing.FramingRecord.WriteChunkedPayload(Boolean endOfRecord, Boolean endOfMessage, Byte[] bytes, Int32 offset, Int32 count)
bei Microsoft.Web.Services3.Messaging.Framing.FramingRecord.WriteChunkedPayload(Boolean endOfRecord, Boolean endOfMessage)
bei Microsoft.Web.Services3.Messaging.Framing.FramingRecord.Close(Boolean endOfMessage)
bei Microsoft.Web.Services3.Messaging.Framing.FramingStream.Close()
bei Microsoft.Web.Services3.Mime.MimeWriter.Close()
bei Microsoft.Web.Services3.Mime.XopPackageWriter.WriteAnyExtractedContent()
bei Microsoft.Web.Services3.Mime.XopPackageWriter.WriteFullEndElement()
bei System.Xml.XmlElement.WriteTo(XmlWriter w)
bei System.Xml.XmlDocument.Save(XmlWriter w)
bei Microsoft.Web.Services3.Mime.XopDocument.SaveToXopPackage(Stream stream, String infosetContentType, String boundary, String startId)
bei Microsoft.Web.Services3.Messaging.SoapMtomFormatter.SerializeMessage(Stream stream, SoapEnvelope envelope, String mimeBoundary, String startId)
bei Microsoft.Web.Services3.Messaging.SoapMtomFormatter.Microsoft.Web.Services3.Messaging.ISoapFormatter.Serialize(SoapEnvelope envelope, Stream stream)
bei Microsoft.Web.Services3.Messaging.SoapMtomFormatterWithFraming.Microsoft.Web.Services3.Messaging.ISoapFormatter.Serialize(SoapEnvelope envelope, Stream stream)
bei Microsoft.Web.Services3.Messaging.SoapTcpConnection.SerializeMessage(SoapEnvelope envelope)
bei Microsoft.Web.Services3.Messaging.SoapTcpTransport.Send(SoapEnvelope envelope, EndpointReference destination)
bei Microsoft.Web.Services3.Messaging.SoapTcpOutputChannel.Send(SoapEnvelope message)
bei Microsoft.Web.Services3.Messaging.SoapReceiver.DispatchMessage(SoapEnvelope message)
bei Microsoft.Web.Services3.Messaging.SoapReceiver.ProcessMessage(SoapEnvelope message)
--- Ende der internen Ausnahmestapelüberwachung ---</faultstring>
<faultactor>soap.tcp://chimera/SyncService</faultactor>
</soap:Fault>
Google erzählt mir dazu leider gar nichts. Reflector bringt mich zu der Einsicht, dass der Socket unerwartet geschlossen wurde.
Die Protokollierung des Clients zeigt garkein Fehler.
Hat jemand ne Idee was man noch versuchen könnte bzw. woran es liegen kann?
ich habe einen Datentransfer zwischen einem als WindowsService gehosteten Webservice und einem Client, beide verwenden WSE3 und das soap.tcp Protokoll.
Die Kommunikation zwischen beiden funktioniert soweit.
Jedoch bricht die Übertragung ab einer bestimmten SOAP Envelope größe einfach ab und der Client wartet ewig auf die Antwort vom Service und die Anwendung friert ein.
Es greift komischer Weise auch kein Timeout bei der Funktion : Microsoft.Web.Services3.WebServicesClientProtocol.Invoke(<WebMethodName, <ParameterObject>).
Ich hab mir das mal mit Wireshark angeschaut und der TCP Stream zum Client reißt einfach mitten im Envelope ab.
Ich hab leider keine Einstellungen bezüglich irgendwelcher Transfergrößen oder deren Dauer gefunden.
Die mit wsewsdl3 Tool generierte Proxyklasse für soap.tcp funktioniert erst ab einem Framework ≥ 3. Da auf Funktionen zugegriffen werden, die im 2.0 NotImplementetExceptions werfen.
Wenn man die VisualStudio Integration von WSE3 aktiviert und einen Webverweis erzeugt wird funktionierender Code generiert.
Nach einigen Reflector Sessions weiß ich nun wieso es nicht geht ..
man endet beim deserialisieren immer in einem Aufruf von throw new NotImplementetException der in einem try / catch Block gekapselt ist und das auch nicht nach außen liefert.