Re: Fragen an Alaska
Verfasst: Do, 29. Apr 2010 12:29
Ich habe die sehr ausführliche Antwort gerade erhalten. In Kürze näheres.
Das deutschsprachige Forum für Entwickler in der Xbase-Welt, ein Angebot des Deutschsprachige Xbase-Entwickler e. V.
https://www.xbaseforum.de/
Und das sind die Antworten:1. Wann kommt Unicode-Unterstützung?
2. Wann kommt UTF-8-Unterstützung?
3. Aktualisierung der OP-Lock/Registry-Schalter-Geschichte für moderne Betriebssysteme wurde in Aussicht gestellt - wann? (Anm. TL: Dabei geht es wohl darum, dass die Informationen, die Alaska vor einiger Zeit zum Thema OpLocking bereitgestellt hat, für Vista/Windows 7 mit SMB2 nicht mehr aktuell sind.)
4. WAA mit Dateiupload?
5. WAA mit MS-Excel-Ansteuerung?
6. Einfache Möglichkeit mehrere WAA-Server zu starten und Prozesse zu verteilen (Socket-Error-Problem...)?
7. Gewünscht ist das normale Windows List View Control als XbpListView(). Wird es das geben?
8. Es fehlt die Möglichkeit, im Kalender-Control (wie im Beispiel) Feiertage mit dem Attribut "BOLD" zu versehen.
9. Wenn seit 2007 bekannt ist, dass der Indexkey keine 512 Zeichen lang sein darf, dies aber immer noch in der Anleitung so steht. Und das auch noch blau unterlegt, was doch m.W. bedeuten soll, es wurde aktualisiert seit der letzten Version. (Anm. TL: Es scheint aber noch nicht zu funktionieren.)
10. XppFD: ClassCode: In der INIT wird Position und Größe fix hinterlegt ... aber erst nach ::super:create kann man mit diese per SetPos() wieder ändern ... das kostet ZEIT und ist unnötig. BESSER wäre es, wenn beide als Instanzvariablen verfügbar wären, dann könnte man in der eigenen INIT ... oder vor CREATE noch umsortieren ...
Code:
oSLE:aCurPos := { nZeile, nSpalte }
oSLE:aCurSize := { nHeigth, nWidth }
oSLE:create()
11. Steffen hat mal (war das in Berlin zum XUG-Treffen 2006?) gesagt, Xbase++ wäre bereit für 64 Bit. Müßte nur noch ein Compilerschalter umgelegt werden. Da mit Windows 7 sehr viele Kunden auf 64 Bit umsteigen: Wäre es dann nicht an der Zeit, das dann auch rauszugeben?
12. Ist es noch in Planung, Xbase++-DLL's für andere (nicht Xbase++-Programme) nutzbar zu machen?
13. Wird die max. Dateigröße bei DBFDBE (aktuell 2,4GB) und bei FOXDBE (aktuell 2GB) zukünftig erhöht oder die Größenbeschränkung ganz aufgehoben?
14. Was ist mit der Memofile-Größe bei FOXDBE (aktuell auf 2GB limitiert), während die Größe bei DBFDBE-Memofiles unlimitiert ist?
15. Wann wird es "Artica" REALISTISCH geschätzt geben?
Hallo Tom,
leider hat es etwas länger gedauert. Hier nun die Antworten.
Zu 1.) & 2.)
Das Thema Unicode und UTF8 möchte ich zusammen behandeln. Hierzu gilt es folgendes festzuhalten.
a.) Mit der Xbase++ 2.0 wird es UTF8 converter wie CToUTF8() und UTF8ToC() geben. Die PostgreSQL DatabaseEngine sowie die ODBC Engine unterstützen jeweils Unicode daten transparent. Die PostgreSQL DBE speichert alle Characterdaten grundsätzlich in Unicode/UTF8 - dies damit multi-nationale Anwendungen einfachst möglich sind.
b.) Mit Visual Xbase++ 3.0 oder aber erst mit 3.5 wird es dann Unicode 32 in der gesamten Runtime geben. Früher ist aus praktischen Erwägungen nicht möglich. Es herrscht nämlich im Unicode Umfeld ein ganz schönes Chaos.
I.) Die Windows Platformen Windows 95/98/Me kennen kein Unicode insofern bedeuted Unicode bei Xbase++ auch die Aufgabe der Unterstützung dieser Betriebssysteme.
II.) Windows selbst ist Unicode 1 (16Bit Unicode), also eigentlich ein veralteter Unicode Standard der gar nicht so viel im internationalen/globalisierten Rahmen hilft. Die Xbase++ runtime soll aber Unicode 2 also 32Bit Unicode beherrschen, nur das macht Sinn.
III.) UTF8 ist ganz nett, leider ist UTF8 bereits veraltet, aus praktischen Erwägungen muss auf UTF16 gegangen werden. Hierbei fehlen uns aber noch konkrete Messdaten und theoretische Berechnungen für eine Runtime - will sagen wie hoch verändert sich die Systemlast einer UTF16 vs. UTF8 versus 8Bit Characterset Application sowohl im Bereich CPU Last als auch im Bereich Speicherverbrauch. Berechnungen, sowie Tests bzgl. UTF8 haben wir im letzten Jahr getätigt, selbiges fehlt uns aber noch für UTF16 - dies ist wichtig um zu prüfen/beweissen das UTF16 bei 32Bit Prozessen noch Sinn macht oder aber nur im Kontext der Transition zu 64Bit von Vorteil ist.
Grundsätzlich gilt aber unabhängig von Xbase++ das eine UTF16 oder UCS Repräsentation der Zeichendaten und das verarbeiten derselbigen mehr CPU Last sowie mehr Hauptspeicher benötigt.
Notiz: Wenn wir - also Alaska Software - von einer Unicode Unterstützung Sprechen so reden wir davon das die Runtime auf der Grundlage von Unicode Characterdaten arbeitet, nur so können die jeweiligen Windows API als Unicode API angesteuert werden. D.h., zwei XbpStatics können gleichzeitig ohne spezifische Konfiguration oder aber Font selection unterschiedliche Zeichensätze darstellen. Ein XbpBrowse würde den DE Kunden in Zeile 1 mit DE Sonderzeichen und den Polnischen Kunden in Zeile 2 mit PL Sonderzeichen ausgeben. Alle Operationen auf Zeichenketten verhalten sich entsprechend was aber dann zur folge hat:
// default compile-schalter /ca characters treated as ascii
cbBinaryText := b"Hallo"
cText := "Hallo"
cuUnicodeText := u"Hallo"
Obiger Beispielcode zeigt das es dann einen Binary-Character-Literal geben muss dies damit binäre Daten verwaltet werden können. SubStr(cbBinaryText,1,1) liefert das erste Byte. Ein SubStr( cText,1,1) liefert das erste Zeichen welches 1 byte gross ist. Und x := SubStr(cuUnicodeText,1,1) liefert das erste Zeichen welches aber bis zu 4 byte gross sein kann aber nicht sein muss. Also Len(x)==1 <> ByteLen(x)==4, deshalb muss im Rahmen der Unicode Umstellung einiges getan werden - und zwar auf Seiten des Anwendungsentwicklers da es für Xbase++ nicht immer klar sein kann ob hier Zeichen oder Bytes im String verwaltet werden.
// mit /cu characters treated as unicode
cbBinaryText := b"Hallo"
cText := a"Hallo"
cuUnicodeText := "Hallo"
Wie aus den beiden Szenarien erkennbar. Ist das default Verhalten des compilers so ausgelegt das bei einem Umstieg auf unicode minimalste Korrekturen notwendig sind. Wird aber von vorneherein auf Unicode entwicklelt so bietet sich die /cu Einstellung da auf das explizite verwenden des literalen Bezeichners u"" verzichtet werden kann.
Zu 3.) Hier ist die Situation dahingehend als das ein Ausschalten von SMB2 unter Vista zwar möglich war, aber nur unter Vorbehalt. Denn A.) Groove und andere Office-Merkmale im Bereich Collaboration/Dateisynchronisation sind bei ausgeschaltetem SMB2 schlichtweg nicht verfügbar - da diese auf SMB2 aufsetzen - insofern war es in der Praxis so das die meisten Administratoren ein SMB2 ausschalten nicht zugelassen haben. Und B.) ein Ausschalten via Windows API und Manipulation des Registry von der Xbase++ Applikation aus gar nicht mehr ging - der API läuft zwar anstandslos durch die Registry-Manipulation fand nur in der Shadow-Kopie des Registry fuer die Anwendung manipulierende Anwendung statt. Das OS hatte nach wie vor SMB2 eingeschaltet, da der Registry gar nicht manipuliert wurde - dieses Verhalten ist aufgrund der neuen Sicherheitsrichtlinien von Vista so korrekt und definiert.
Seit Server 2008 und Windows 7 ist dies nun alles wieder Geschichte, SMB2 lässt sich nicht mehr ausschalten - es liegen uns aktuell auch keine Informationen darüber vor, das mit SMB2 es zu Problemen kommt, insofern "scheint" es aktuell eher so zu sein, das eine Verwendung von SMB2 zu empfehlen ist! Das auschalten von OP Locking in SMB1 ist ja dokumentiert. Wir hatten zu diesem Themenkomplex eine Video-Konferenz mit MS wg. OP Locking und SMB2 im letzten Jahr und uns wurde versichert das die Patterns welche unter SMB1 zu Datenverlust und/oder korrupten Dateien udgl. führten in SMB2 nicht mehr existieren, auch hat MS LAB angedeuted das mit zukünftigen Server Produkten nach Server 2008 wieder mehr der Fokus auf die Performance des konkurrierenden Dateizugriffes gelegt wird, da dieses Nutzungsmodell mit Server 2003 aus dem Fokus der Entwicklung verschwunden ist, es sich aber gezeigt hat das hier ein Bedarf am Markt besteht. Diese Aussagen sind leider nur von der Entwicklung und nicht vom Management also muss man leider warten was daraus wird. Einzig und allein gilt das auf jeden Fall Vista mit Servicepack eingesetzt werden muss, ohne ServicePack und SMB2 gibt es Probleme beim Locking siehe hierzu. Server 2008 und Win7 haben diese defekte nicht!
http://support.microsoft.com/kb/935366/en-us
Zu 4.) Eine neue WAA Version mit Datei-Upload wird zur Zeit gepackaged, auf der Grundlage von 1.90 SL1 und sollte innerhalb der nächsten Wochen/längstens 2
Monate verfügbar sein.
Zu 5.) Was ist darunter zu verstehen? WAA & Excel Ansteuerung? Ist damit office-automation in einer WAA Anwendung gemeint? Wenn ja, so sollte das gehen!
Zu 6.) Der neue WAA sollte weniger Socket-Error Probleme haben, wir haben hier Korrekturen angebracht. Wenn du aber load-balancing meinst so ist das eine Frage des Gateways und der Session-Datenbank, wir hatten da mal experimentel etwas gemacht. Woher kommt denn genau die Anforderung? Was ist hier der Hintergrund?
Zu 7.) Wir haben die XbpListView() auf die Wunschliste der PartPacks gesetzt.
Zu 8.) Auf welches Beispiel beziehts du dich denn?
Zu 9.) Die Dokumentation ist meines erachtens hier nicht vollständig. Wir Sprechen von der CDXDBE? Wenn ja dann gilt wie in der Doku: Index & For _Expression_
maximal 512 byte zusammen! Eine Aussage über die Index-Key länge wird in der CDXDBE Doku nicht gemacht. Es gilt, diese ist auf 240 Zeichen beschränkt. Jedoch sind dies bei der CDXDBE im Visual FoxPro mode (default) maximal 120 Zeichen da für jedes Zeichen 2 Byte verwendet werden - Ausnahme hiervon ist die Collation-Table MACHINE diese verwendet ein Byte pro Zeichen. Im Comix Modus stehen immer die 240 Zeichen zur Verfügung.
Nochmal, vorgenannte Längen gelten für den Schlüsselwert und sind zu 100% Identisch mit den "Grenzwerten" von Visual FoxPro und bedingt durch das Index-Datei-Format. Längere Schlüsselwerte sind bei CDX Systembedingt nicht möglich, im übrigen sind derart Lange Schlüsselwerte sowieso ein Problem im allgemeinen bei jeder Datenbank (auch SQL) da die Schlüssellänge meist im direkten Verhältniss zur Performance des indexes steht. Vor allem grosse Schluessel Also (>100 Zeichen) mit einer hohen identität also zum Beispiel die ersten 50 Zeichen sind in 50% der Fälle gleich führen zu einer erheblichen Degradierung der Zugriffsperformance bei Datenbanken im allgemeinen. Hier helfen dann nur noch Hash-Indexe für das Suchen diese sind aber nicht geeignet eine Navigation zu unterstützten.
Zu 10.) Leider verstehen wir hier deine Ausführungen nicht, kannst du uns ein konkretes Beispiel des Problemes aufzeigen - bitte nicht die Lösung sonder
das Problem/den Nachteil. Dank hierfür vorab.
Zu 11.) Wenn eine bestehende Xbase++ 32Bit Applikation als 64Bit Applikation compiliert und gelinkt wird, so konsumiert diese ca. 2.5 mal mehr Physischen-Hauptspeicher und läuft ca. 40% langsamer! Selbiges gilt natürlich auch für eine .NET oder C/C++ oder was auch immer Anwendung im Kontext von aktueller Hardware! Mit anderen Worten, für Regelanwendungen macht 64Bit heute keinen Sinn, die einzige Ausnahme sind Applikationen die grosse Datenmengen >~2GB im Hauptspeicher verarbeiten müssen. Dieser Anwendungstype ist aber eine Minorität. Was ist also der Vorteil von 64Bit, nunja um es klar zu sagen - wichtig ist das ein 64Bit Betriebssystem eingegesetzt wird und darauf dann 32Bit Prozesse laufen, das ist aktuell und mit Hinblick auf die Hardware-Entwicklung noch für ca. 3-4 Jahre das optimum. Warum?! Bedenke, ein 32Bit OS kann maximal 3GB RAM Adressieren, d.h. aber auch die 3GB RAM muessen sich alle Prozesse und das OS teilen! Egal wieviel virtuel in Summe durch alle Prozesse verbraucht wird, es stehen aus der Sicht eines 32Bit OS immer nur diese 3GB zur Verfügung. Verwenden wir nun eine 64Bit Platform mit 24GB RAM, und einem 64Bit OS so stehen allen Prozessen und dem OS in Summe 24GB RAM zur Verfügung - es ist also möglich mehrere 32Bit Prozesse die jeweils 3GB Hauptspeicher im Zugriff haben mit "echtem" RAM zu versorgen - auf einem 32Bit OS undenkbar. Damit sollte klar sein, warum ein 64Bit OS sehr viel Sinn gerade fuer 32Bit Prozesse macht und warum selbst MS zwar das erstellen von 64Bit Anwendungen unterstützt aber Entwicklungsumgebung oder MS Offfice nach wie vor nur als 32Bit Applikationen verfügbar sind - okay, mit Office 2010 - wurde gestern released gibt es auch eine 64Bit Version - aber selbst MS Rät von der Verwendung ab, Gründe sind schlechtere Performance, bestehende VB macros gehen nicht mehr wegen typen (32Bit vs. 64Bit) und ActiveX AddOns sind in den seltensten Fällen als 64Bit verfügbar. Nur Kunden die spezielle Anforderungen wie Excel Spreadsheets > 2GB haben sollten auf dezidierten Maschinen Office 2010 64Bit einsetzten.
Wir testen zur Zeit die Xbase++ Runtime mit Hinblick auf die Möglichkeit bis zu 4GB Hauptspeicher pro Anwendung zu verwalten, denn 64Bit Betriebssystemem können auf Anforderung des Anwendungsprozesses den gesamten 32Bit Addressraum als Speicher zur Verfügung stellen! Das würde dann mit Hinblick auf Xbase++ 32Bit Prozesse einer näherungsweise Verdoppelung des verfügbaren Hauptspeichers zur Folge haben ohne Performance einbussen. Abschliessend noch der Hinweis, bzgl. des Performanceverlustes bei 64Bit OS und 64Bit Anwendungen, das Problem sind die Cache-Lines der CPUs diese sind sehr kostspielig in der Produktion, bei einem 64Bit Anwendungsprozess sind diese aber doppelt so schnell erschöpft es tritt viel früher ein cache trashing auf und damit ein erheblicher Performancenachteil. Selbst die Intel CoreI7 Prozessoren haben als L1 nur einen 64Kb Cache der sich in 32KB Daten und 32KB Instructionen aufteilt, an der Aufteilung erkennt man schon für welchen Anwendungstyp der Prozessor konstruiert wurde - auf jeden Fall nicht für 64Bit Da ja auch der Hauptspeicher Bedarf steigt und eine durchschnittliche Maschine die 64Bit OS und 64Bit Anwendungen ausführt um die 12GB RAM haben sollte haben wir aktuell noch das Problem das ein derartiger RAM Ausbau nur mit 4GB Riegeln möglich ist, Stichwort Kosten der Hardware.
Wir verfolgen diese Entwicklung sehr genau, und werden wenn es ökonomisch für unsere Kunden Sinn macht auch eine 64Bit Version bereitstellen, gehen aber heute davon aus das wir mit der 64Bit Version die 32Bit Version ablösen werden und planen nicht 2 unterschiedliche Entwicklungspakete 32Bit & 64Bit zu warten und zu supporten.
Abschliessend noch der Hinweis das eine Migration auf 64Bit gar nicht so einfach ist sobald mittels DLLCall Windows oder Fremd-APIs Anwendung fanden auch sind ActiveX Komponenten nicht immer als 64Bit verfügbar!
12.) Wir hatten hier zwar einige Nachfragen in den letzten 24 Monaten, bei genauerem Nachhacken stellte sich aber heraus das alle Anforderung durch Verwendung von Web-Services oder aber TCP/IP IPC Kommunikation besser lösbar waren - insofern haben wir hier keine konkreten Pläne, im Rahmen der .NET Unterstützung wird diese Thematik ja dann sowieso gelöst da dann diese Anforderung ein gefordertes Leistungsmerkmal der Platform ist.
13.) Bzgl. der Dateigroessen der DBFDBE gilt, Standard und Kompatibel zu Clipper sind max. 1GB, die 2,4GB Dateigroesse sind nur möglich bei Änderung des Lockingoffsets - siehe DBFDBE_LOCKOFFSET in der DBFDBE Dokumentation. Die Größenbeschränkungen bei der DBF Datei aufzuheben würde bedeuten wir würden ein eigenes properitäres Format einführen - hier stellt sich schlichtweg die Frage nach dem realen Nutzen. Für die DBFDBE werden wir das mit sicherheit nicht tun - da wir ja bereits jedem Anwender empfehlen auf die FOXDBE zu gehen - hier wäre es denkbar aber der Bedarf ist relative - die größten Probleme existieren ja mit BLOB oder Grossen-Textdaten. Diese Beschränkungen wurde aber im SL1 aufgehoben siehe hierzu die FOXDBE Dokumentation. FPT Dateimaximum ca. 16Terabyte, bei default-blockgroesse von 64bytes sind dies bereits 128GB.
Zu 14.) Siehe vorherige Antwort, deine Aussage, vor allem das die Groesse der DBFDBE unlimitiert ist ist fuer mich nicht nachvollziehbar. Ausserdem sollte die DBFDBE also DBT nicht mehr verwendet werden - Stichwort: DBFDBE DBTs können keine Binärdaten speichern!
Zu 15.) Definitiv dieses Jahr. Realistisch Juni oder aber Juli 2010.
So, das war jetzt eine Menge, ich denke das beste ist du liest es dir durch, notierst dir deine Fragen und wir machen einen Telefontermin in dem ich die aus meinen Antworten resultierenden Fragen dir im Gespräch beantworte - ich denke das wäre so am besten.
Abschliessend noch besten Dank an dich und die "anderen" für die Fragen.
Dies mit besten Gruessen,
na das wollen wir doch "sehen" ...Definitiv dieses Jahr. Realistisch Juni oder aber Juli 2010.
AUGE_OHR hat geschrieben: ... schon mal versucht IP6 "abzuschalten" ?
Hast du irgendeine "neue" Aussage entdecken können ?Tom hat geschrieben:Heute ist wieder so ein Tag.
zu meinem Erstaunen musste ich auch wieder eine ganze Zeit suchen ...> Frage 8.
> Es fehlt die Möglichkeit, im Kalender-Control (wie im Beispiel)
> Feiertage mit dem Attribut "BOLD" zu versehen.
Zu 8.) Auf welches Beispiel beziehts du dich denn?
Ich habe hier einen PowerBasic FormDesigner der gibt als auswählbareD:\ALASKA\ALASKA.190-SL1\XPPW32\source\samples\solution\XBPDPICK
hier bei der Auswahl des Datums über das Windows DatePicker Control.
Das XbpMonthView hat zwar einige Methoden um DayBold etc. Tage
fett anzuzeigen, aber es ist uns bisher nicht gelungen z.B.
die Samstage, Sonntage und freie Feiertage eines Monats BOLD
angezeigt zu bekommen.
So wie ich das sehe ist das alles Windows pur, sollte also auch mit Xbase++ gehen.Control sends MSN_GETDAYSTATE message to the parent to get a list of
days to show in bold.
OK, ich versuche es nochmals.> Frage 10.
> XppFD: ClassCode: In der INIT wird Position und Größe fix hinterlegt
> ... aber erst nach ::super:create kann man mit diese per SetPos() wieder
> ändern ... das kostet ZEIT und ist unnötig. BESSER wäre es, wenn beide
> als Instanzvariablen verfügbar wären, dann könnte man in der eigenen
> INIT ... oder vor CREATE noch umsortieren ...
> Code:
> oSLE:aCurPos := { nZeile, nSpalte }
> oSLE:aCurSize := { nHeigth, nWidth }
> oSLE:create()
Zu 10.) Leider verstehen wir hier deine Ausführungen nicht, kannst du uns
ein konkretes Beispiel des Problemes aufzeigen - bitte nicht die Lösung sondern
das Problem/den Nachteil. Dank hierfür vorab.
CLASS Code verwendet man, damit der Painter-CODE in der _X.PRG Datei von
den manuellen Änderungen inder X.PRG getrennt ist. Der XbpFD ist ja
nicht das gelbe vom Ei, speziell beim Ausrichten mit der Maus ist
schnell mal die Größe eines Controls geändert statt der Position.
Wiederrufen kann er auch nicht. Außerdem tue ich mich schwer damit
mit der Maus auf Pixel Ebene zu so richtig gut zu zielen.
1. Paintern und speichern und Classcode erzeugen:
Nun habe ich also x.prg und _x.prg, die captions, activate etc.
passen nicht ganz bzw. sind noch leer.
2. Schritt im x.prg das anpassen was ich ändern will ...
:caption := ... // geht, kein Problem
:activate := {|| meineFunktion() } // geht, super ...
nun habe ich noch die ??? XbpStatic und XbpSle für die Eingabe...
ich müsste die Position und die Größe anpassen ..., !
Die Höhe der Controls habe ich in einer CH Datei hinterlegt (nSLEHoehe, nPBHoehe ...)
Ich weiß alles, aber habe keine iVars: POS und SIZE ...
das ist das Problem.
Lösung 1, die _X.PRG anpassen, dann ist keine weitere Änderung von XppFD möglich !
Lösung 2, in X.PRG create aufrufen, dort SUPER create ... dann
je control:setPosAndSize(...) aufrufen ...
das kostet Zeit und ist völlig unnötig, wenn man einfach die iVars
:POS oder :aPOS und :SIZE oder :aSize zugänglich machen würde.
Da ich schon seit längerem mit TOP LEFT arbeite ist die manuelle
Umsetzung im Quellcodeeditor schon mühsam, aber zumindest habe ich
nun seit SL1 je die Innenmaße und beim Resize flackert es nicht mehr.
Klar, wenn man immer nur einzelne fragt, wird man die Antwort bekommen: Ich brauche das (z.B. die Kompatibilität) nicht, mir wäre es lieber, mehr damit tun zu können - wir alle kennen das aus Gesprächen mit unseren Kunden. Aber das Format ist nun einmal ein Standardformat. Diejenigen, die migrieren wollen, aber gleichzeitig noch konkurrierend oder mit anderen Tools auf die Tabellen zugreifen wollen, brauchen die Kompatibilität. Und davon abgesehen gibt es viele Alternativen. FOX, zum Beispiel, aber auch das enorm flexible ADT, auf das jeder mit der ADSDBE zugreifen kann - unter ADSLOCAL auch ohne Advantage Database Server. Und SQL, z.B. per SQLExpress (oder Artica, ab Juli ). Davon abgesehen gibt es Methoden, um mit den Schwächen von DBF (von Größenbegrenzungen abgesehen) umgehen zu können. Eindeutige Zähler kann man selbst implementieren. Binärdaten lassen sich speichern, wenn man sie nach Hex konvertiert.Ich finde es schade, das Alaska anscheinend nicht darüber nachdenkt, die aktuellen dbf zu erweitern. Klar gibt es die Kompatibilitätsfrage. Aber wie viele von uns sind darauf angewiesen?
In meinen Augen ist es ein Argument.das mit der Kompatibilität ist meines Erachtens nur eine Ausrede.
man könnte a.) einen "Schalter" setzen und b.) "gemeinsam" benutzte DBF/Index müssen einem "Standart" (Cl*pper) entsprechen.Klar gibt es die Kompatibilitätsfrage
em ... äh ... "ich" kann chinesische Zeichen in DBFNTX "speichern" und auch mit entsprechenden IME "editieren".Aber was ist, wenn ich dringend UTF-8 (Unicode wäre natürlich besser) brauche, und zwar auf einem Einplatzsystem? Muß ich da wirklich erst mächtige Datenbanken installieren, damit das funktioniert?
Du kannst DBU unter Xbase compilieren (kleinere Anpassungen) und es geht fast gleich wie das Alte.Koverhage hat geschrieben: Ich brauche die Kompatibilität auch nicht. Momentan benutze ich zwar ab und an noch DBUP, aber
da würde sich sicherlich Ersatz für finden.
Hättest du vielleicht ein paar Zeilen Code, wie man das machen kann.Eindeutige Zähler kann man selbst implementieren.
bedeutet das, dass das im neuen WAA funktioniert (vom 1.6.10)?Zu 4.) Eine neue WAA Version mit Datei-Upload wird zur Zeit gepackaged, auf der Grundlage von 1.90 SL1 und sollte innerhalb der nächsten Wochen/längstens 2
Monate verfügbar sein.
Ja, etliches getestet, nix gehtZu 5.) Was ist darunter zu verstehen? WAA & Excel Ansteuerung? Ist damit office-automation in einer WAA Anwendung gemeint? Wenn ja, so sollte das gehen!
=D>Zu 6.) Der neue WAA sollte weniger Socket-Error Probleme haben, wir haben hier Korrekturen angebracht.
Ich weiss, wäre doch schön, wenn das öffentlich wäre - klar kann man auch selber bastelnWenn du aber load-balancing meinst so ist das eine Frage des Gateways und der Session-Datenbank, wir hatten da mal experimentel etwas gemacht. Woher kommt denn genau die Anforderung? Was ist hier der Hintergrund?
Hallo Otto,azzo hat geschrieben:@Tom
Hallo Tom,
ich habe in einem Beitrag über dbf von dir gelesen:Hättest du vielleicht ein paar Zeilen Code, wie man das machen kann.Eindeutige Zähler kann man selbst implementieren.
Vielen Dank im voraus.
Gruß
Otto