Das Forentreffen 2018 findet am 20./21. April in Dresden statt. Weitere Infos hier
Anmeldungen zum Forentreffen 2018 sind auf der Anmeldeseite möglich
Zur Homepage des Deutschsprachige Xbase-Entwickler e. V.
Xbase++-Wiki des Deutschsprachige Xbase-Entwickler e. V.

SQLite ... als DBF Ersatz

Alles zum PostgreSQL-Server

Moderator: Moderatoren

Antworten
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 13811
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

SQLite ... als DBF Ersatz

Beitrag von brandelh » Di, 30. Sep 2008 10:57

Hallo,

ich habe schon mehrfach von SQLite gelesen und nun bei Pablo folgende
Xbase++ ZIP angesehen. Das sieht recht gut aus:

http://www.xbwin.com/forum.html
Start > Forums > xfree.resources (readonly) > SqLite 3 demo suite

Die Beispiele sind zwar auf spanisch aber auch im PowerBasic Forum wird
SQLite wegen der einfachen Verwaltung (alles in einer Datei) und
Geschwindigkeit für "normale" Anwendungen hoch gelobt.
In einer Firma mit vielen Anwendern wird man sicher einen
SQL Server nehmen, aber als DBF Ersatz scheint mir SQLite
doch recht geeignet.

Infos zu SQLite:
http://de.wikipedia.org/wiki/SQLite
http://www.sqlite.org/

Hat von euch schon jemand Erfahrung damit ?
Gruß
Hubert

georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1951
Registriert: Fr, 08. Feb 2008 21:29

Re: SQLite ... als DBF Ersatz

Beitrag von georg » Mo, 28. Mai 2012 11:40

Guten Morgen,


auch wenn das Thema jetzt vier Jahre (oder fast) zurückliegt, möchte ich es noch einmal aufgreifen.

Für einige Anwendungen, die mehr oder weniger Single-User Programme sind, bin ich auf der Suche nach einem DBF-Ersatz, der möglichst nicht den Overhead einer SQL-Server Installation mitbringen soll. SQLite stach mir da ins Auge, da es ja z.B. bei FireFox im Hintergrund eingesetzt wird.

Ausgehend von der Version, deren Link Hubert gepostet hat, bin ich noch auf Folgendes gestossen:

http://www.xbwin.com/sqlite/

Allerdings komme ich mit der Klassen-Implementierung nicht klar, und ich bin mir nicht sicher, ob paralleler Zugriff auf mehrere Tabellen aus einer Datenbank funktioniert oder nicht.


Basierend auf der Implementierung aus 2008 habe ich mal einen Benchmark gefahren, bei dem ich ca. 12.000 Datensätze (alle Datentype, 35 Felder, viele Memo-Felder) in eine neue Tabelle geschrieben habe, einmal via ODBC und SQLExpress, und einmal mittels der OT4XB Variante.

ODBC: ca. 950 Sekunden
OT4XB: ca. 250 Sekunden

Hierbei spielt aber auch die ODBC Implmentierung eine Rolle, aber ich denke, dass ich lieber auf die OT4XB-Variante zurückgreife.

Hat einer von Euch in der letzten Zeit mit SQLite gearbeitet und kann mir Ratschläge geben?


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg

Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 13749
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Kontaktdaten:

Re: SQLite ... als DBF Ersatz

Beitrag von Martin Altmann » Mo, 28. Mai 2012 11:46

Moin Georg,
die vor der Tür stehende Xbase++-Version nutzt SQLite. Insofern wird jeder (bald) die ersten Erfahrungen damit sammeln können.
Dies nur als kleiner Hinweis für die weiteren Mitleser - Du weißt es ja schon, da Du ja damals bei der JHV 2011 anwesend warst.

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: http://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: http://meldungen.altem.de/

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1951
Registriert: Fr, 08. Feb 2008 21:29

Re: SQLite ... als DBF Ersatz

Beitrag von georg » Mo, 28. Mai 2012 12:51

Hallo, Martin -


leider kann ich nicht erkennen, ob's Ironie ist, die aus Deinem Beitrag spricht, oder nicht. Ich erinnere mich an ein Treffen in Rösrath, bei denen der Release-Zeitpunkt auch "Ende des Jahres" war. Da ich nicht länger auf Alaska warten kann (/will), suche ich derzeit nach Alternativen.

Eine Analyse meiner Programme zeigt, dass ich in den meisten Fällen mit nativen SQL-Befehlen arbeiten kann, nur das Thema Browse-Datenquelle war schwierig, aber auch dafür habe ich jetzt eine Klasse geschrieben, die mittels SQLExpress das gleiche Verhalten zeigt, wie ein Anwender es bisher kennt.

Wenn Alaska dann irgendwann etwas passendes auf den Markt bringt, bin ich gerne bereit, wieder ein Benchmarking durchzuführen. Jetzt interessiert mich der Einsatz von SQLite, weil ich JETZT Probleme habe, die gelöst werden müssen, und nicht warten können.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg

Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 13749
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Kontaktdaten:

Re: SQLite ... als DBF Ersatz

Beitrag von Martin Altmann » Mo, 28. Mai 2012 12:55

Moin Georg,
nein - keine Ironie. Sonst wäre da irgendwo ein Smiley gewesen.
Ich rede von der JHV, auf der Du mit Deinem Sohn auch einen Vortrag gehalten hattest. Aber egal - ich wollte ja nur allgemein darauf hinweisen, dass relativ bald jeder Nutzer von Xbase++ mit SQlite seine Erfahrungen sammeln kann, so er will.

Viele Grüße,
Martin
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: http://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: http://meldungen.altem.de/

Mitglied der XUG Osnabrück
stellv. Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 10657
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: SQLite ... als DBF Ersatz

Beitrag von AUGE_OHR » Mo, 28. Mai 2012 16:08

Martin Altmann hat geschrieben:die vor der Tür stehende Xbase++-Version nutzt SQLite. Insofern wird jeder (bald) die ersten Erfahrungen damit sammeln können.
so wie mit PostgreSQL ? ja die MIGration läuft ja ganz nett, aber was ist mit Xbase++ v2.0.426 "selbst" ?
gruss by OHR
Jimmy

Benutzeravatar
azzo
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 224
Registriert: So, 28. Mär 2010 19:21

Re: SQLite ... als DBF Ersatz

Beitrag von azzo » Mo, 28. Mai 2012 16:56

Hallo Georg,
>Für einige Anwendungen, die mehr oder weniger Single-User Programme sind, bin ich auf der Suche nach einem DBF-Ersatz
Warum suchst du einen Ersatz für DBF.
Welche Gründe gibt es dafür.
mfg
Otto

georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1951
Registriert: Fr, 08. Feb 2008 21:29

Re: SQLite ... als DBF Ersatz

Beitrag von georg » Mo, 28. Mai 2012 18:35

Hallo, Otto -


wenn Du bis heute nicht an die Grenzen von DBF/NTX/CDX gestossen bist, sei froh ...

Eine DBF Datei sowie die zugeordneten Index-Dateien sind unabhängige Entitäten. In dem Moment, in dem Du eine DBF Datei öffnest, ohne alle Index-Dateien ebenfalls zu öffnen, und Daten änderst/löschst/hinzufügst, ist die Integrität zwischen Daten und Index hin. Ein SQL-Server (selbst wenn wir von SQLite reden, das ja kein Server im eigentlichen Sinn ist) kümmert sich implizit um die Integrität zwischen Daten und Index.

DBF/NTX/CDX lässt kein echtes UNIQUE zu. Darunter verstehe ich, dass es mir nicht möglich ist, einen Satz anzulegen (oder so zu ändern), dass der Schlüssel mit einem bereits bestehenden Schlüssel kollidiert. Ein SQL-Server regelt dies z.B. über PRIMARY KEY.

Und gerade beim Betrieb im Netzwerk (spezielle Konstellation) ist FOXCDX extrem lahm. 5 Stunden via Netzwerk, 10 Minuten auf dem lokalen PC. Allerdings muss diese Anwendung übers Netz laufen.

Programmtechnisch bietet mir SQL deutlich Vorteile, z.B. in der Gruppenverarbeitung, weil ich die Sätze, die mein Programm erhält, bereits vorab filtern und sortieren kann.

Soviel in der Kürze der Zeit.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 13811
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: SQLite ... als DBF Ersatz

Beitrag von brandelh » Mo, 28. Mai 2012 19:51

Wenn ich Steffen richtig verstanden habe, sollen native SQLite Zugriffe möglich sein.
Alaska sieht dies eher für die Zugriffe von Android Smartphone Dateien, daher glaube ich nicht, dass es eine vollwertige DBE gibt,
aber ich lass mich überraschen.

Bei der Frage ob ODCB oder NATIV, wurden wir dahingehend belehrt ( ;-) ) dass heute beide nahezu gleich schnell sein sollen
(ODBC routet durch native API ...). Ob SQLite multiuser fähig ist und eine DBFDBE ersetzen könnte, weiß ich nicht.

Bei der Betrachtung gehe ich einen anderen Lösungsweg.
Wenn ich damit rechne, dass das Zielsystem vom Anwender bestimmt werden soll, nehme ich ODBC (SQLExpress).
Wenn ich die Daten vor dem Anwender verstecken will, dann würde ich einen nativen Zugriff bevorzugen.

Was Arctica bringen wird, werde ich testen wenn ich eine stabile Xbase++ Vorversion und ZEIT dazu habe ;-)
Gerade letzteres fehlt mir aktuell an allen Ecken, daher habe ich auch noch nicht viel experimentiert.
Gruß
Hubert

georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1951
Registriert: Fr, 08. Feb 2008 21:29

Re: SQLite ... als DBF Ersatz

Beitrag von georg » Mo, 28. Mai 2012 20:04

Hallo, Hubert -


bezüglich der Geschwindigkeit: es gibt keine "offizielle" ODBC-Version für SQLite, daher kann ich über die Qualität der ODBC-Treiber Implementierung wenig sagen. Allerdings spricht die Zeit für sich.

Aus dem Abschnitt "Situations Where Another RDBMS May Work Better" schliesse ich, dass SQLite multi-user fähig sein sollte:

http://www.sqlite.org/whentouse.html

Wie gesagt, mir brennt ein Problem auf den Nägeln, und da kann ich leider nicht auf Alaska warten, sondern muss selbst aktiv werden.

Bisher sieht es aber so aus, dass noch keiner hier reingeschaut hat, der SQLite im Einsatz hat?


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg

Benutzeravatar
Jan
Foren-Administrator
Foren-Administrator
Beiträge: 12486
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

Re: SQLite ... als DBF Ersatz

Beitrag von Jan » Mo, 28. Mai 2012 20:14

brandelh hat geschrieben:Was Arctica bringen wird, werde ich testen wenn ich eine stabile Xbase++ Vorversion und ZEIT dazu habe ;-)
Gerade letzteres fehlt mir aktuell an allen Ecken, daher habe ich auch noch nicht viel experimentiert.
Ich werde VX 2.0 testen, sobald ich etwas mehr Zeit habe. Und ich endlich eine Anleitung erhalte, wie ich VX 2.0 parallel zu 1.9 installieren und nutzen kann. Trotz dreifacher Nachfrage hat mir das in Isernhagen am Donnerstag Abend niemand erklärt/erklären können. Außerdem stört es mich extrem, das ich VX 2.0 (zumindest in der Conference-Version) nicht auf DEM Laufwerk und in DEM Verzeichnis installieren kann, das ICH gerne hätte. Ich dachte immer, die Zeiten der Gängelungen durch Betriebssystemvorgaben wäre zumindest in diesem Punkt lange vorbei.

Ansonsten würde ich schon gerne SQLite verwenden. Für Endanwender scheint das eine tolle Variante zu SQL zu sein, da hier kein Administrationsaufwand auf den Privatanwender zukommt. Und er kann (hoffentlich) selber entscheiden, wo er die Daten speichern will, was bei den "großen" SQL-Versionen schlecht geht. Auch verschiedene Datenbestände in verschiednenen Verzeichnissen.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
azzo
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 224
Registriert: So, 28. Mär 2010 19:21

Re: SQLite ... als DBF Ersatz

Beitrag von azzo » Mo, 28. Mai 2012 23:03

Hallo Georg,
danke für deine Antwort.
Wir macht man bei SQLite eine Satzsperre.
Wenn die Daten im Browser angezeigt werden, wie handhabt man das Neueinlesen bzw. das Vor- und Rückwärtsblättern damit man immer die aktuellen Daten sieht.

mfg
Otto

georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1951
Registriert: Fr, 08. Feb 2008 21:29

Re: SQLite ... als DBF Ersatz

Beitrag von georg » Di, 29. Mai 2012 5:17

Guten Morgen, Otto -


Deine Fragen enthalten mehr Sprengstoff als Du ahnst ...

SQL operiert eigentlich nicht mit Satzsperren, die Du als Programmierer setzt. Ein konkurrierendes Update musst Du selbst abfangen - aber das ist ein Problem, dass sich generell bei SQL Servern stellt, und damit eben auch bei SQLite.

Für den Einsatz beim Browsing habe ich eine eigenen Klasse entwickelt, die das alles regelt. Ich bin gerade im Gespräch mit dem Vorstand, dass ich bei der Mitgliederversammlung einen Vortrag über dieses Thema halte.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 13811
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: SQLite ... als DBF Ersatz

Beitrag von brandelh » Di, 29. Mai 2012 8:43

Ich nutze SQLite auf Android Smartphones, dort gibt es sowas wie konkurierenden Zugriff nicht.
Ich denke aber, dass die folgende Aussage auch auf PC - SQLite und Server zutrifft:
  1. Satzsperren werden intern automatisch gehandhabt, man kann diese nichts selbst auslösen. (Arctica mit PostgreSQL im ISAM Modus könnte eine Ausnahme sein ...).
  2. Aktuelle Daten anzeigen, setzt immer einen neuen SELECT Befehl voraus ...
  3. Bei einem Browse, dass hunderte Spalten und tausende von Zeilen durchsuchen muss, sollte man sich gut überlegen ob das automatisch alle Sekunde einen neuen SELECT absetzen soll ...
  4. Die Programmlogik muss von "ich sperre einen Satz, bearbeite diesen und gebe den wieder frei ..." auf die mengenbasierte Verarbeitung umstellen.
  5. Grundsätzlich kann der gleiche Datensatz immer an mehreren Stationen gleichzeitig geändert worden sein.
    Felder wie Vorname und Name kann man sicher einfach abspeichern, denn selbst wenn zwei SB den Vornamen ändern, sollte der gleiche Inhalt heraus kommen.
    Sehr problematisch sind offene Posten in Rechnungen (2 Stationen verkaufen den gleichen Artikel, es ist aber nur noch einer auf Lager. Hier muss man Vorsorge treffen.
Gruß
Hubert

Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 475
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Re: SQLite ... als DBF Ersatz

Beitrag von Alfred » Di, 29. Mai 2012 16:49

SQL-Lite als embedded ist meines Wissens nicht multiuserfähig.

Zum Thema Satzsperren. SQL-Server(nicht embedded) verwalten grundsätzlich
nach dem Motto wer zu erst kommt malt zu erst.

Bei embedded Server solltest Du einen Blick auf den ADS(embedded ist kostenlos)
oder Firebird(< 2.5) werfen. Ob man für Firebird einen nativen Zugriff mit otx4b hinbe-
kommt weis ich leider nicht.

Gruß
Alfred

georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1951
Registriert: Fr, 08. Feb 2008 21:29

Re: SQLite ... als DBF Ersatz

Beitrag von georg » Mi, 30. Mai 2012 9:53

Alfred hat geschrieben:SQL-Lite als embedded ist meines Wissens nicht multiuserfähig.
...

Gruß
Alfred
Hallo, Alfred -

Of those that are serverless, SQLite is the only one that this author knows of that allows multiple applications to access the same database at the same time.
Hier gefunden:

http://sqlite.org/different.html

Spricht mir dafür, dass zumindest parallele Zugriffe möglich sind, und ob die von einem PC mit mehreren Programmen, oder von mehreren PCs kommen, scheint mir unerheblich.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 13811
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: SQLite ... als DBF Ersatz

Beitrag von brandelh » Mi, 30. Mai 2012 13:07

Hi,

Soweit mir bekannt ist funktioniert Android nicht so wie wir es gewohnt sind !
Ein Fenster das in den Hintergrund geht, wird angehalten !
Es kann sogar vom OS komplett zerstört werden wenn der Speicher eng wird.
Erst wenn es wieder nach vorne geholt werden soll, wird das Fenster über einen Event wieder aufgebaut.
Somit gibt es vom OS her kein Multitasking und somit auch keinen Multiuser Zugriff.
Selbstverständlich kann eine Anwendungen mehrere offene Handles auf die SQLite Engine haben und auch verschiedene Abfragen auf verschiedene Handles ausführen.
Diese werden nacheinander abgearbeitet !
Auf die gleiche Art wird übrigens auch die Windev SQL DB auf Windows Mobile 6.5 Smartphones betrieben.

Für PowerBasic gibt es Client/Server Implementation für die SQLite Engine ( http://www.planetsquires.com/sqlite_client_server.htm ),
was vermuten läßt, dass die API Zugriffsschnittstelle dies nicht unbedingt automatisch erledigt.
Ich habe damit aber noch keine Erfahrungen gesammelt. Bei Pablo gibt es Beispielcode den jemand zur Verfügung gestellt hat,
dieser hat gut funktioniert, allerdings speichert der verschiedene Datentypen im gleichen Feld.
Meldet also keinen Fehler wenn man eine Zahl in ein Textfeld schreiben will.

Ob diese Implementierung automatisch multiuser fähig ist weiß ich nicht.
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 10657
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: SQLite ... als DBF Ersatz

Beitrag von AUGE_OHR » Mi, 30. Mai 2012 19:41

hi,

kennt ihr von Hector Pezoa die XBMySql() Class ? die beinhaltet ja schon die "Navigation"

das Sqlite Sample ist typisch Pablo ;) kurz und knapp und deshalb gibt es auch nur die Procdure PERFORM(db,cQuery)

Hector hat in seiner Class die Method(en) zur "Navigation" Xbase typisch ausgelegt und macht dann dort den API Call.

Code: Alles auswählen

DLL libmysql IMPORT mysql_affected_rows AS LONG ;
DLL libmysql IMPORT mysql_autocommit AS BOOL ;
DLL libmysql IMPORT mysql_change_user AS BOOL ;
DLL libmysql IMPORT mysql_character_set_name AS ZSTRING ;
DLL libmysql IMPORT mysql_close AS VOID ;
DLL libmysql IMPORT mysql_commit AS BOOL ;
DLL libmysql IMPORT mysql_create_db AS INT ;
DLL libmysql IMPORT mysql_data_seek AS VOID ;
DLL libmysql IMPORT mysql_debug AS VOID  ;
DLL libmysql IMPORT mysql_drop_db AS INT32 ;
DLL libmysql IMPORT mysql_dump_debug_info AS INT32 ;
DLL libmysql IMPORT mysql_eof AS BOOL  ;
DLL libmysql IMPORT mysql_errno AS UINT ;
DLL libmysql IMPORT mysql_error AS ZSTRING ;
DLL libmysql IMPORT mysql_field_count AS UINT ;
DLL libmysql IMPORT mysql_field_seek AS DWORD  ;
DLL libmysql IMPORT mysql_field_tell AS DWORD;
DLL libmysql IMPORT mysql_free_result AS VOID ;
DLL libmysql IMPORT mysql_get_client_info AS ZSTRING
DLL libmysql IMPORT mysql_get_client_version AS ULONG
DLL libmysql IMPORT mysql_get_host_info AS ZSTRING ;
DLL libmysql IMPORT mysql_get_proto_info AS UINT ;
DLL libmysql IMPORT mysql_get_server_info AS ZSTRING ;
DLL libmysql IMPORT mysql_get_server_version AS ULONG  ;
DLL libmysql IMPORT mysql_info AS ZSTRING  ;
DLL libmysql IMPORT mysql_init AS POINTER32 ;
DLL libmysql IMPORT mysql_kill AS INT    ;
DLL libmysql IMPORT mysql_library_end  AS VOID
DLL libmysql IMPORT mysql_list_dbs AS POINTER32 ;
DLL libmysql IMPORT mysql_list_fields AS POINTER32 ;
DLL libmysql IMPORT mysql_list_processes AS POINTER32 ;
DLL libmysql IMPORT mysql_list_tables AS POINTER32 ;
DLL libmysql IMPORT mysql_more_results AS BOOL ;
DLL libmysql IMPORT mysql_next_result AS INT ;
DLL libmysql IMPORT mysql_num_fields AS UINT ;
DLL libmysql IMPORT mysql_num_rows AS DWORD  ;
DLL libmysql IMPORT mysql_options AS INT  ;
DLL libmysql IMPORT mysql_ping AS INT ;
DLL libmysql IMPORT mysql_query AS INT    ;
DLL libmysql IMPORT mysql_real_connect AS POINTER32 ;
DLL libmysql IMPORT mysql_reload AS INT ;
DLL libmysql IMPORT mysql_rollback AS BOOL  ;
DLL libmysql IMPORT mysql_row_seek AS DWORD  ;
DLL libmysql IMPORT mysql_row_tell AS DWORD ;
DLL libmysql IMPORT mysql_select_db AS INT ;
DLL libmysql IMPORT mysql_set_server_option AS INT ;
DLL libmysql IMPORT mysql_shutdown AS INT  ;
DLL libmysql IMPORT mysql_sqlstate AS ZSTRING ;
DLL libmysql IMPORT mysql_ssl_set    AS INT ;
DLL libmysql IMPORT mysql_stat AS ZSTRING ;
DLL libmysql IMPORT mysql_store_result AS POINTER32 ;
DLL libmysql IMPORT mysql_thread_id AS ULONG ;
DLL libmysql IMPORT mysql_use_result AS POINTER32  ;
DLL libmysql IMPORT mysql_warning_count AS UINT ;
Frage : ich kann ja sicherlich die MySQL API Structure auf die SqLite API Structur "mappen" ... aber wie ?

wenn es sich um Xbase Code handeln wäre würde ich #Xtranslate verwenden wärend es sich bei den API Calls um unterschiedliche Structure handelt.

Code: Alles auswählen

BEGIN STRUCTURE MYSQL_FIELD
  MEMBER DYNSZ   name                 // Name of column
  MEMBER DYNSZ   org_name             // Original column name, if an alias
  MEMBER DYNSZ   table                // Table of column if column was a field
  MEMBER DYNSZ   org_table            // Org table name, if table was an alias
  MEMBER DYNSZ   db                   // Database for table
  MEMBER DYNSZ   catalog	           // Catalog for table
  MEMBER DYNSZ   def                  // Default value (set by mysql_list_fields)
  MEMBER ULONG   length               // Width of column (create length)
  MEMBER ULONG   max_length           // Max width for selected set
  MEMBER LONG    name_length
  MEMBER LONG    org_name_length
  MEMBER LONG    table_length
  MEMBER LONG    org_table_length
  MEMBER LONG    db_length
  MEMBER LONG    catalog_length
  MEMBER LONG    def_length
  MEMBER LONG    flags                // Div flags
  MEMBER LONG    decimals             // Number of decimals in field
  MEMBER LONG    charsetnr            // Character set
  MEMBER LONG    nType                // Type of field. See mysql_com.h for types
END STRUCTURE
Frage : wo findet man Informationen über Sqlite Structure z.b. von FF ? ... und die von PostgreSQL .. ?
gruss by OHR
Jimmy

Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 475
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Re: SQLite ... als DBF Ersatz

Beitrag von Alfred » So, 03. Jun 2012 19:07

Hallo Georg,

Du sollstest testen, wie sich das in einem Browse auswirkt.
1.2 Date and Time Datatype

SQLite does not have a storage class set aside for storing dates and/or times. Instead, the built-in Date And Time Functions of SQLite are capable of storing dates and times as TEXT, REAL, or INTEGER values:

TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").
REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.

Applications can chose to store dates and times in any of these formats and freely convert between formats using the built-in date and time functions.
Ich kann das leider nicht ausprobieren, da meine zusätzlich gekauften Zugriffskomponenten unter Delphi
zwar einige SQL-Datenbanken unterstützen. SQlite ist jedoch leider nicht dabei.

Gruß
Alfred

georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1951
Registriert: Fr, 08. Feb 2008 21:29

Re: SQLite ... als DBF Ersatz

Beitrag von georg » So, 03. Jun 2012 20:43

Hallo, Alfred -


hoffentlich komme ich in den nächsten Tagen dazu, das mal auszuprobieren, dann werde ich das Ergebnis berichten.

Grundsätzlich gehe ich davon aus, dass bei einer Nutzung von SQLite einiges an Feldtyp-Konvertierung bei mir als Programmierer hängenbleibt. Da ich aber meistens alles in eine Klasse packe, kann ich beim Übergeben der Daten an mein Programm auch ein paar Konvertierungen vornehmen, so dass Xbase++ das "sieht", was es sehen soll.

Falls Du unter Deinen Komponenten eine hast, die einen Zugriff über ODBC erlaubt, dann installiere doch mal den SQLite-ODBC Treiber und versuche es damit. Im Zusammenspiel mit SQLExpress hat der Treiber recht gut funktioniert.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg

georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1951
Registriert: Fr, 08. Feb 2008 21:29

Re: SQLite ... als DBF Ersatz

Beitrag von georg » Mo, 04. Jun 2012 12:52

Hallo, Alfred -


in der Zwischenzeit habe ich mal zwei Versuche gestartet.

Unter Verwendung der ODBC-Schnittstelle werden die Daten typ-konform geliefert, d.h. eine Zahl wird als Zahl, ein Datum als Datum geliefert (wobei ich den Verdacht habe, dass Boris hier - wie üblich - ganze Arbeit geliefert hat und die Typkonvertierung anhand der Tabellenstruktur vornimmt).

Unter Verwendung von OT4XB werden alle Inhalte als CHAR zurückgeliefert, also auch Datum, Zahlen, etc.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg

Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 475
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Re: SQLite ... als DBF Ersatz

Beitrag von Alfred » Di, 05. Jun 2012 21:52

Hallo Georg,

ich habe es zwischenzeitlich geschafft eine SQlite-Datenbank mit einer Tabelle manuell anzulegen.

Dabei zeigt sich das es einen Datentyp Datum tatsächlich nicht gibt.
Zum Abfragen der Daten gibt es jedoch Datums- und Zeitfunktionen.

Hier noch eine Bestätigung zu diesem Thema:

http://www.linux-magazin.de/Heft-Abo/Au ... (offset)/2
Auch wenn SQLite-Autor Richard Hipp diese Typfreiheit in der Dokumentation als Vorteil darstellt, bringt sie einige potenzielle Probleme mit sich. So sind dann häufig Werte als Zahlen identisch, aber als String verschieden, zum Beispiel »1.0« und »1.00«. Das verletzt aber das Grundprinzip relationaler Datenbanken, dass der Anwender das interne Speicherformat nicht kennen muss.
Besonders fehlerträchtig ist das bei Datum-Strings, die je nach verwendetem Format (TT.MM.JJ, JJ.TT.MM und so weiter) verschiedene Bedeutungen haben. Im schlimmsten Fall ist nicht mal gewährleistet, dass in einem Datumsfeld überhaupt ein Datum steht, denn SQLite akzeptiert aufgrund der Typlosigkeit auch »bla« als Datum.
Somit ist ein direktes Arbeiten mit einem Datagrid oder den Datenbankfelder nicht möglich, wenn ein Datumsfeld mit dabei ist und man keine unsinnigen Daten im Datenfeld haben möchte.

Folgende Probleme habe ich zudem derzeit noch mit dem ODBC-Zugriff.

In der manuell angelegten Datenbank steht im Namen Müller im Datagrid Mller.

Ein Request Live wird mit dem Hinweis Table read only abgelehnt.
Da müssen sicher noch die entsprechenden Locks gesetzt werden.

Für meine Zwecke macht SQLite3 derzeit keinen Sinn, da ich auf meine Server direkten Zugriff habe
und der CS Firebird-Server alle meine Anforderungen voll erfüllt und mir beim Datenzugriff die Arbeit
vollständig abnimmt.

Gruß
Alfred

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 10657
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: SQLite ... als DBF Ersatz

Beitrag von AUGE_OHR » Mo, 01. Okt 2012 23:17

georg hat geschrieben:
Alfred hat geschrieben:SQL-Lite als embedded ist meines Wissens nicht multiuserfähig.
Hier gefunden:

http://sqlite.org/different.html

Spricht mir dafür, dass zumindest parallele Zugriffe möglich sind, und ob die von einem PC mit mehreren Programmen, oder von mehreren PCs kommen, scheint mir unerheblich.
wenn du mehrere PC hast die gleichzeitig zugreifen wollen dann muss einer den "Server" spielen ... und erst hier ist das "sperren" interessant.

http://sqlite.org/whentouse.html#appfileformat
Situations Where Another RDBMS May Work Better
a.. Client/Server Applications

If you have many client programs accessing a common database over a
network, you should consider using a client/server database engine instead
of SQLite. SQLite will work over a network filesystem, but because of the
latency associated with most network filesystems, performance will not be
great.

b.. Also, the file locking logic of many network filesystems
implementation contains bugs (on both Unix and Windows). If file locking
does not work like it should, it might be possible for two or more client
programs to modify the same part of the same database at the same time,
resulting in database corruption. Because this problem results from bugs in
the underlying filesystem implementation, there is nothing SQLite can do to
prevent it.

c.. A good rule of thumb is that you should avoid using SQLite in
situations where the same database will be accessed simultaneously from many
computers over a network filesystem.
gruss by OHR
Jimmy

Antworten