Daten auf SQL Server übertragen

[Thomas (Gast)]

Hi,

ich habe einen uC mit Internetanbindung.
Dieser uC nimmt jede Minute ein paar Sensordaten auf.
Diese Sensordaten sollen in einer SQL Datenbank gespeichert werden, die 
auf einem Webserver liegt.

Externen SQL Zugang erlaubt mein Provider nicht.

Jede Minute ausführen:
http://www.server.de/log.php?date=14.02.2013&time=12:33:12&a=12.33&b=55.77

Weiß jemand was besseres?

Gruß,
Thomas

[Peter II (Gast)]

Thomas schrieb:
> Weiß jemand was besseres?

ist doch gut, was soll man da noch verbessern?

[Thomas (Gast)]

Keine Anhnung, das Web kenne ich bisher nur von Anwenderseite.
Ich könnte mir z.B. vorstellen das es nicht so toll ist regelmäßig 
Verbindungen aufzubauen und man besser in größeren Abständen größere 
Datenmengen übertragen sollte.
Dann währe noch die Frage wie, also was gibt es sonst noch für 
Möglichkeiten.
FTP-Upload würde mir noch einfallen, aber es gibt bestimmt noch 
Web-Technologien von denen ich noch nie gehört habe.
Kann ja auch sein, dass jemand sagt: "Alles außer direkter SQL Zugang 
ist mist, also wechsel deinen Webhoster."

[TestX .. (xaos)]

HTTP gateway ist doch standard für solche dinge... direktes sql macht 
man eigtl nie..

[Vlad T. (vlad_tepesch)]

Thomas schrieb:
> Jede Minute ausführen:
> http://www.server.de/log.php?date=14.02.2013&time=...
>
> Weiß jemand was besseres?

was spricht denn dagegen? Das ist dochj optimal.
Für den µC keine Arbeit außer ein Request. Der Server mach die ganze 
Arbeit.

[Deneriel (Gast)]

Ein Verbesserungsvorschlag meinerseits wäre, dass du noch eine 
Authentifizierung einbaust. Und prüfe die Eingaben auf plausibilität. 
Klassisches Beispiel ist die Eingabe

name"; drop all databases;

in ein Formularfeld. Security trough obscourity funktioniert nicht.

[Vlad T. (vlad_tepesch)]

http://xkcd.com/327/

[Peter II (Gast)]

Deneriel schrieb:
> Und prüfe die Eingaben auf plausibilität.
> Klassisches Beispiel ist die Eingabename"; drop all databases;
> in ein Formularfeld. Security trough obscourity funktioniert nicht.

dafür sollte man mit prepared sql arbeiten, dann kann da nichts 
passieren.

[T.roll (Gast)]

Einfach mal raten, da man ja nichts genaues von dir weiß:

Wenn du für deinen Webspace SSH hast, kannst du die Verbindung zur DB 
damit auf deinen PC tunneln.

[Thomas (Gast)]

Danke, Leute!

Funktioniert.

@Vlad: lol

@T.roll:
ssh Tunnel würde gehen, ist hier aber sicher nicht praktikabel.

[Verwirrter Anfänger (Gast)]

Wenn du mit einer zeitlichen Genauigkeit von ca. 5 Sekunden auskommst, 
würde ich die Zeit einfach auf dem Server mit generieren und 
abspeichern. Idealerweise willst du die Zeit eh als Linux Timestamp 
haben und dadurch sparst du dir einen Kalender auf dem Controller und 
ein paar Daten bei der Übertragung.

Wenn deinen µC mal der Strom ausfällt hast du auch keine Probleme mit 
unsinnigen Einträgen in der DB, und du must dir keine Gedanken um 
Schaltjahre, Schaltsekunden, Sommerzeit / Winterzeit, etc... machen.

[Thomas (Gast)]

Ja, guter Vorschlag.
Zumindest bei der Übertragung könnte ich das auch so machen.
Wenn die Übertragung aus irgend einem Grund schief läuft speichert er 
die Werte aber zunächst lokal auf einer SD-Karte und synchronisiert 
diese dann nach der nächsten erfolgreichen Übertragung wieder. Daher 
muss die Zeit eh permanent laufen.

Nach einem Stromausfall holt der uC sich die aktuelle Zeit per NTP.
Eine Pufferung der RTC per Goldcap ist auf der TODO Liste.

[Vlad T. (vlad_tepesch)]

Verwirrter Anfänger schrieb:
> Wenn deinen µC mal der Strom ausfällt hast du auch keine Probleme mit
> unsinnigen Einträgen in der DB, und du must dir keine Gedanken um
> Schaltjahre, Schaltsekunden, Sommerzeit / Winterzeit, etc... machen.

Man kann ja auch im Controller Unix-Sekunden zählen.
Dann fällt das Kalender-Gedöhns auch weg. Das Problem mit Zeit nach 
Restart besorgen bleibt natürlich trotzdem.

[Thomas (Gast)]

> Man kann ja auch im Controller Unix-Sekunden zählen.
Genau so läuft es auch.