Accessing Form-Data by means of ODBC

Hello
Deutscher Text am Ende.

I have been using VisForms for two years and am very happy with it!

For a new application would like to read the contents of the VisForm forms via ODBC directly over the Internet on the Web server and thereby e.g. also set a flag or proccess dates in the SQL database, possibly even correct data entry errors. The changed data should then be retrievable by users on the web server. So far I used an old version of the ODBC driver. This worked wonderfully!

But the newer versions now require a field of type Timestamp in every record you want to manipulate. Oracle writes in the 'MySQL Connector/ODBC Developer Guide': "Include a TIMESTAMP in all tables that you want to be able to update." With phpMyAdmin I can create such a timestamp-field without any problems. I would put it as the last field in the record and I have already done that on a trial basis, it worked.

But with something like this you can't test every eventuality (inserting or deleting fields, ...). For example, I could imagine that Visforms searches through all existing fields when adding fields and then it comes to a problem, as after the timestamp follow some more Fxxx fields...

Can you give me some non-binding advice on where not to put the timestamp - or where to put it. Non-binding because I know that I am leaving the standard functionality and that there can be no guarantee from a manufacturer like Visforms!

Another idea would be of course if I would add a field from the timestamp directly to VisForms and thereby support the ODBC driver...

---
Hallo

Ich brauche seit zwei Jahren VisForms und bin damit sehr zufrieden!

Für eine neue Anwendung möchte die Inhalte der VisForm Formulare über ODBC direkt über das Internet ab dem Webserver lesen und dabei z.B. auch mal ein Flag oder Verarbeitungsdatum in der SQL-Datenbank auf dem Webserver setzen, ev. sogar Erfassungsfehler korrigieren. Die Daten sollen dann auf dem WebServer auch wieder von Benützern abgerufen werden können. Bisher habe ich dazu eine alte Version des ODBC Treibers verwendet. Das hat wunderbar funktioniert!

Die neueren Versionen verlangen nun aber, dass in jedem Datensatz den man manipulieren will ein Feld vom Typ Timestamp vorhanden ist. Oracle schreibt dazu im 'MySQL Connector/ODBC Developer Guide': "Include a TIMESTAMP in all tables that you want to be able to update." Mit phpMyAdmin kann ich so einen Timestamp-Feld problemlos erzeugen. Gefühlsmässig würde ich den als letztes Feld im Datensatz unterbringen und habe das auch probehalber bereits gemacht, hat funktioniert.

Aber bei sowas kann man natürlich nicht jede Eventualität durchtesten (einfügen oder löschen von Feldern, …). Ich könnte mir zum Beispiel vorstellen, dass Visforms sich beim Zufügen von Feldern durch alle bestehende Felder durchsucht und es dann zu einem Problem kommt, weil nach dem Timestamp noch Fxxx Felder folgen…

Kannst Du mir einen unverbindlichen Ratschlag erteilen, wo ich den Timestamp nicht unterbringen darf - oder wo ich ihn unterbringen soll. Unverbindlich darum, weil mir klar ist, dass ich damit die Standardfunktionalität verlasse und dass es dafür keine Garantie von einem Hersteller wie Visforms geben kann!

Eine andere Idee wäre es natürlich wenn ich bei VisForms direkt ein Feld vom Timestamp zufügen würde und dadurch den ODBC-Treiber unterstützen würde…

Hello Blacksmith,
Deutscher Text am Ende!

Visforms does not rely on the field-order in its data tables.
As far as I can see, additional fields in general should not cause any unexpected behavior.
This holds as long as the added 'external' field must not be handled by Visforms in any way - in other words: can co-exist completely transparent to Visforms.
Obviously, additional fields - regardless of the type - configured with properties like 'no default value set' and 'null is not allowed' set at the same time, render Visforms immediately useless when saving new form data.

Your changes in the data table structure ought still to be properly tested!

As I am interested in and actually quite wondering about this new harsh requirement in these newer versions of ODBC MySQL Connector from Oracle - now requiring a field of type Timestamp in every record you want to manipulate - could you please provide me with a link to the documentation you mentioned?

Best regards,
Aicha

--- Deutscher Text

Visforms verlässt sich nicht auf die Feldreihenfolge in seinen Datentabellen.
Soweit ich sehen kann, sollten zusätzliche Felder im Allgemeinen kein unerwartetes Verhalten verursachen.
Dies gilt, solange das hinzugefügte 'externe' Feld in keiner Weise von Visforms behandelt werden muss - mit anderen Worten: es kann vollständig transparent für Visforms koexistieren.
Im Speziellen macht ein zusätzliches Tabellenfeld - unabhängig vom Typ - konfiguriert mit Eigenschaften wie 'kein Standardwert gesetzt' und 'null ist nicht erlaubt', wenn gleichzeitig gesetzt, Visforms beim Speichern neuer Formulardaten selbstverständlich sofort nutzlos.

Deine Änderungen in der Datentabellenstruktur sollten trotzdem unbedingt getestet werden!

Da ich an dieser neuen Anforderung der neueren Versionen des ODBC MySQL Connectors von Oracle interessiert bin, und mich eigentlich auch ziemlich darüber wundere, wäre ich dir sehr dankbar, wenn du mir einen Link zur besagten Dokumentation geben könntest.

Hello Aicha
Deutscher Text am Ende!

Thanks for the quick, detailed and - for me also very positive - answer.

The timestamp field does not need any handling by Visforms, it contains date and time when the record was created/modified and is updated without user action. That I test this thoroughly is self-evident....

As for the Oracle requirement: it's been around for quite a while - roughly guessed it could be 10 years! I used an old version of the ODBC driver for a few years and never had any problems with the functions I used. According to my installation instructions, however, the timestamp field was already postulated in version 5.1 of the ODBC driver for #DELETED# problems. Even with version 8 of the ODBC driver, read queries are still possible without the additional field without any problems (this is how I have been accessing Visforms data for the last 2 years).

In the current version 8 I find the requirement for the timestamp field only for accesses with Access: docs.oracle.com/cd/E17952_01/connector-o...tor-odbc-errors.html . In version 5.1, the description was more detailed and, to my recollection, necessary for other database environments as well. I never understood why this timestamp field is necessary - with the very old drivers (3.51?) write accesses worked without the additional field.

If you have further questions, I can try to find more info in my old documentations.

Kind regards,
Blacksmith

--- Deutscher Text

Danke für die rasche, ausführliche und – für mich auch sehr positive – Antwort.

Das Timestamp-Feld benötigt keinerlei Behandlung durch Visforms, es enthält Datum und Zeit wann der Datensatz angelegt/modifiziert wurde und wird ohne Benutzeraktion aktualisiert. Dass ich das gründlich teste ist selbstverständlich…

Was die Erfordernis von Oracle betrifft: Es gibt die durchaus schon länger – grob geschätzt könnten es 10 Jahre sein! Ich habe damals ein paar Jahre lang eine alte Version des ODBC Treibers verwendet und hatte mit den von mir benutzten Funktionen niemals Mühe. Gemäss meinen Installationsanleitungen war aber bereits in der Version 5.1 des ODBC Treibers das Timestamp-Feld bei #DELETED#-Problemen postuliert. Auch mit Version 8 des ODBC-Treibers sind Leseabfragen immer noch problemlos ohne das zusätzlich Feld möglich (so habe ich die letzten 2 Jahren auf Visforms-Daten zugegriffen).

In der aktuellen Version 8 finde ich die Erfordernis für das Timestamp-Feld nur noch für Zugriffe mit Access: docs.oracle.com/cd/E17952_01/connector-o...tor-odbc-errors.html . Bei der Version 5.1 war die Beschreibung ausführlicher und meiner Erinnerung nach auch für andere Datenbankumgebungen notwendig. Warum dieses Timestamp-Feld notwendig ist habe ich nie verstanden – mit den ganz alten Treibern (3.51?) funktionierten schreibende Zugriffe ohne das zusätzliche Feld.

Falls Du weitere Fragen dazu hast, kann ich gerne versuchen in alten Dokumentationen von mir noch mehr Info zu finden.