Fragen an Alaska

Vorschläge, Infos, Verbesserungen, Technisches

Moderator: Moderatoren

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von Tom »

Ich habe die sehr ausführliche Antwort gerade erhalten. In Kürze näheres.
Herzlich,
Tom
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Fragen an Alaska

Beitrag von Manfred »

Komisch,

immer direkt nach einer Frotzelei.... :lol:
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von Tom »

So, hier nun die Antwort aus Eschborn. Das waren die Fragen:
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?
Und das sind die Antworten:
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,
Herzlich,
Tom
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Fragen an Alaska

Beitrag von Manfred »

Menno,

den Rat mit der FOXDBE anstatt der DBFDBE habe ich wohl total überhört. Ich kann mich nicht daran erinnern, dass der jemals öffentlich irgendwo gefallen ist.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Fragen an Alaska

Beitrag von AUGE_OHR »

hi,

hm ... Wenn ich ein Kunde wäre und ich würde ihm so was erzählen ...
Es wurden zwar viele "Erklärungen" (und Entschuldigungen) geliefert aber keine TERMINE, also wieder nur "blabla" ...
Es interessiert weder den Kunden noch die Xbase++ Anwender welche "Probleme" zu lösen sind, es interessiert nur das es gemacht wird ... jetzt ... heute ...

ad 1.) alle Ausführungen beziehen sich auf < Win7, denn Win7 ist 32Bit Unicode
.... und das mit DBCS sage ich schon die ganze Zeit ...

ad 3.) das beim Ausschalten von SMB2 auch die Office (2010) Komponenten "beeinflusst" werden
und man es deshalb nicht "einfach" abschalten kann wurde auch schon "gesagt".
Eine "Lösung" wird aber nicht angeboten ... schon mal versucht IP6 "abzuschalten" ?

Auch habe ich ja angesprochen das dass Problem vor allem bei "gemischten" OS() auftritt.
Wenn man nur Win7 / Srv2008 R2 mit Xbase++ mit SMB2 fährt funktioniert das schon, aber sobald 1x SMB1 Gerät im Netzwerk dazu kommt ...

ad 9.) Frage wurde nicht beantwortet.
Es wurden nur "Ausreden" verwenden warum Xbase++ nur 120/240 könne ... komisch das es mit harbour geht ...

ad 11.) interessieren uns wirklich technische "Details" ?
Meine Kunden interessiert das nicht sondern die wollen Lösungen !!!

ad 13.) eine "einfache" Frage die auch wieder nur aus "Ausreden" besteht.
Frage : wessen Interesse steht im "Vordergrund" ? Die der Kunden oder Alaska ?
Wenn ein Kunden "was will" soll er es doch bekommen. Er will keine "Erklärung" warum was angeblich nicht geht ...

ad 15.)
Definitiv dieses Jahr. Realistisch Juni oder aber Juli 2010.
na das wollen wir doch "sehen" ...

Der Versuch mit einer schriftlichen Anfrage scheint mir deshalb "misslungen". Man wird wohl auf diese Art keine "Antworten" von Alaska bekommen.
Wir habe es ja nun die ganze Zeit "im Guten" versucht, es wird Zeit mal andere Seiten aufzuziehen ...
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von Tom »

@Jimmy: Du kannst einem manchmal ganz schön auf den Sack gehen. Heute ist wieder so ein Tag. :wink:
Herzlich,
Tom
Benutzeravatar
Herbert
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1991
Registriert: Do, 14. Aug 2008 0:22
Wohnort: Gmunden am Traunsee, Österreich
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von Herbert »

AUGE_OHR hat geschrieben: ... schon mal versucht IP6 "abzuschalten" ?
:D

Immerhin haben wir einen Dialog...
Grüsse Herbert
Immer in Bewegung...
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Fragen an Alaska

Beitrag von Manfred »

@Jimmy,

@Tom,

tja, was will man dazu sagen?

Was bedeutet "definitiv" ? Das ist jetzt fast 1 Jahr, nee, mit allem drum und dran über 1 Jahr Verzögerung. Was läuft da so schief, oder schwer, dass sich alles wie Gummi der feinsten Art zieht?
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Fragen an Alaska

Beitrag von AUGE_OHR »

hi,
Tom hat geschrieben:Heute ist wieder so ein Tag. :wink:
Hast du irgendeine "neue" Aussage entdecken können ?

Lass uns mal bei SMB2, also Win7, bleiben.
Ich habe vor 2 Jahren (!!!) darauf hin gewiesen als ich die ersten "beta" Test gemacht habe und Alaska hat es "ignoriert".
"jetzt" wo die Leute auf Win7 / Srv2008 R2(!!!) umrüsten und genau die Probleme haben fängt Alaska erst an sich damit zu "beschäftigen" ?

Wenn ich Xbase++ mit Win XP und Win7 und Srv 2008 R2 verwenden will : was muss man tun ?
Das ist doch die Frage und die wird nicht beantwortet. Das nervt !!!
gruss by OHR
Jimmy
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Fragen an Alaska

Beitrag von Manfred »

Obwohl,

das mit Juni Juli 2010 glaube ich. Irgendwie habe ich ein paar Erfahrungen bzgl. Updates und Ablauf meiner Sub. in den letzten Jahren gemacht.. :badgrin:
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von brandelh »

Hi,

ich liefere mal zu den zwei von mir eingereichten Punkten Erklärungen nach, vielleicht hilft es ja ;-)
> 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?
zu meinem Erstaunen musste ich auch wieder eine ganze Zeit suchen ...
Antwort:
D:\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.
Ich habe hier einen PowerBasic FormDesigner der gibt als auswählbare
Eigenschaft MCS_DAYSTATE aus, wenn man das auswählt, wird erklärt
Control sends MSN_GETDAYSTATE message to the parent to get a list of
days to show in bold.
So wie ich das sehe ist das alles Windows pur, sollte also auch mit Xbase++ gehen.
> 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.
OK, ich versuche es nochmals.
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.
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von Jan »

@ Tom,

Dank für die Antwort und all die Arbeit, die dahinter steckt (in diesem Zusammenhang auch an Martin, der ja die Fragen zusammengefasst hat). Aber auch, wenn das eine Menge Arbeit bedeutet: Kannst Du aus der Antwort von Steffen all die Zeilenumbrüche rausnehmen? Das ist echt mühsam zu lesen, und verlängert den Text unnötig und enorm.

OK, Arctica kommt Juni oder Juli definitiv. Das würde bedeuten, daß die 3 Tests à 1 Monat bereits laufen. Denn auch Juli - 3 Monate sind ja April, also jetzt. Oder sehe ich das falsch?

UTF-8 kommt mit 2.0. Das ist schön zu hören. Schlecht ist, daß das anscheinend nicht für dbf gilt, man muß das ja auch mal speichern können (genau das ist im Moment mein ganz großes Problem). Oder verstehe ich das falsch? Und wann kommt denn 2.0? Da sagt Steffen leider garnichts drüber. Und schade, daß Steffen UTF-8 für veraltet hält. Mag ja sein, aber dafür ist das ganz schön verbreitet. Das hat zwar mit dem Thema nicht direkt zu tun, aber selbst im Internet sind die meisten Seiten mit UTF-8 kodiert.

Unicode kommt erst mit 3.0 oder sogar 3.5. Also im nächsten Jahrzehnt. Ganz schön spät. Dafür, das sehr viele andere Programme das bereits können, ist das eigentlich viel zu spät.

Verstehe ich das richtig, das Alaska .Net noch im Hinterkopf hat? da würde ich mir gerne mehr Infos zu wünschen!

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? Ich wäre durchaus damit einverstanden, wenn viel schon an anderen Stellen auch eine inkompatible Erweiterung möglich wäre, die ich für meine Programme anstellen könnte. Dann kann jeder selber entscheiden, ob er dieses inkompatible Feature haben möchte oder lieber kompatibel bleibt.

Aber insgesamt denke ich, diese Fragestunde sollte Tradition werden. Eine gute Möglichkeit, geballt Infos von Alaska zu erhalten. Die aus den Antworten entsehenden Fragen sollten aber ebenfalls abgearbeitet werden können.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von Tom »

Hallo, Jan.

Ich hab's ein bisschen umformatiert. Ist immer noch nicht schön, aber einfacher zu lesen.
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?
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 :wink:). 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.
Herzlich,
Tom
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Fragen an Alaska

Beitrag von Manfred »

@Jan,

was verstehst Du unter geballter Information? Ich sehe da jetzt keinen Zusammenhang. Tut mir echt traurig. :(
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von Jan »

Tom,

schon klar. 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?

Manfred,

war ja klar, wann verstehen wir beide schon auf Anhieb, was der Andere da sagt? :lol: (wenngleich auch meist eher andersherum). Wie Du aus meinem Kommentar sehen kannst, bin ich durchaus kritisch mit dem, was Steffen teilweise schreibt. Aber ihm wurde eine Liste mit hier im Forum pressierenden Fragen gestellt, und er hat sie ausführlich beantwortet. OK, so einiges an seinen Antworten ist eher Politikermäßig (viele Worte, keine Info), oder enttäuschend (Unicode erst in 3.0 oder sogar 3.5). Aber insgesamt kam da eine Vielfalt an Fragen zusammen, die auch noch beantwortet wurden. Ist das denn nichts?

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von Koverhage »

Tom,

das mit der Kompatibilität ist meines Erachtens nur eine Ausrede.
Denn:
1. Alaska müsste nur einen neue DBE schaffen (z.B. XDB für erweiterte DBF). Das dürfte kein großer Aufwand sein.
2. Dann könnte man über die DBE auswählen was man möchte.
3. Leider können wir als Entwickler (so wie auch schon von Phil Ide geplant) kiene zusätzlichen
Formate anlegen. Mir ist bewusst das Alaska dann Probleme mit dem Support bekommen könnte,
wenn durch diese Eingriffe etwas anderes nicht mehr läuft.

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.
Gruß
Klaus
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von Tom »

Hallo, Klaus.
das mit der Kompatibilität ist meines Erachtens nur eine Ausrede.
In meinen Augen ist es ein Argument. :wink:

Gegenfrage: Wenn Du mit DBFNTX nicht weiterkommst, warum benutzt Du dann nicht FOX, ADT oder sogar SQL? Diese Möglichkeiten stehen Dir schließlich offen - schlimmstenfalls müsstest Du eine neue DBE (ADSDBE) oder ein Tool (z.B. SQLExpress) kaufen. Anders gegengefragt: Was fehlt Dir, wofür es keine Alternativen gibt? Oder bist Du nur zu bequem, Deine Anwendung umzustellen?
Herzlich,
Tom
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von brandelh »

Hallo Tom,

aus heutiger Sicht hast du natürlich völlig Recht.

Das Problem sitzt aber viel tiefer, vor Jahren hätte man neben
DBFDBE und FOXDBE für die wichtige Kompatibilität
zusätzlich ein neues Konzept einführen müssen, so wie es VO mit DBSERVER() gemacht hat.
Mehr Power mit Objektorientiertem Zugriff. Die XbpParts gab es in Clipper ja auch nicht ;-)

Heute warten wir halt auf Arctica und hoffen, dass die Verwaltung des PostgreSQL()
automatisch im Hintergrund möglichst einfach möglich ist.
Schließlich kann und will man normalerweise niemandem die Serververwaltung zumuten
wenn ein Betrieb nicht sowieso einen Datenbank Admin hat.

sqllite wäre eventuell auch eine Variante, aber beim konkurierenden Zugriff
bin ich mir nicht sicher was es mitmacht - insbesondere mit Threads ...
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Fragen an Alaska

Beitrag von AUGE_OHR »

Klar gibt es die Kompatibilitätsfrage
man könnte a.) einen "Schalter" setzen und b.) "gemeinsam" benutzte DBF/Index müssen einem "Standart" (Cl*pper) entsprechen.
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?
em ... äh ... "ich" kann chinesische Zeichen in DBFNTX "speichern" und auch mit entsprechenden IME "editieren".
Zugegeben als Font verwende ich ArialUNI.TTF, welcher nicht von Xbase++ stammt ( ala Alaska Crt ), der aber "erwiesen" (Office) chinesische Zeichen (Unicode DBCS) kann.

Auch muss man, wegen der "automatischen" OEM->ANSI Konvertierung, aufpassen ... "abschalten" wäre hier gut.
Nun wird jemand ankommen und sagen : mache es doch mit ANSI ... FALSCH !!!
ANSI geht mit asiatischen Zeichen eben NICHT, man muss wie bei Cl*pper OEM DBF benutzen und dann einen UniCode FONT zum "abspeichern" benutzen.

Es ist im Prinzip das selbe als wenn man "nur" eine Textdatei hätte.
Mittels Notepad und ArialUNI.TTF schreibe ich ("ich lasse schreiben") die "Resourcen" in chinesisch schreiben.
Diese binde ich nun in meine Xbase++ Application ein und kann die auch mit Notepad "ansehen".
Ich darf aber, auf einem German OS(), ohne "passenden" IME nicht in Notepad "editieren" !!!

so war es bislang bei < Win7, denn da "funktioniert" es ?!
In einem Win7 / Srv 2008 R2 Netzwerk kann ich einen chinesischen Win7 PC laufen lassen !
Auch das anlegen und löschen(!!!) von chinesischen Dateinamen und Verzeichnissen(!!!) funktioniert d.h. ich kann es auch von einem deutschen Win7 OS() "löschen" !!! übrigens ... das geht über SMB2 ...

bin ja mal gespannt ob Artica das "beherrscht" ( und ob jemand daran gedacht hat ... ) oder "nur" ANSI machen wird.
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von Tom »

Hallo, Hubert.

Das mag sein - die DBEs waren zunächst vor allem Replacements für die RDDs. Während der ersten Entwicklungsjahre, aber auch heute noch offenbar, stand die Kompatibiltät im Vordergrund, und ich glaube einfach mal, dass sie immer noch sehr wichtig ist. Möglicherweise wurden damals Designentscheidungen getroffen, die zu starr waren, um daraus später ein flexibleres Konzept machen zu können. Andererseits hat VO ja auch mit DbServer letztlich eine Bauchlandung hingelegt - das Produkt ist noch exotischer als Xbase++. Will sagen: Irgendwas ist immer. Aber das beantwortet auch meine Frage nicht, warum man nicht auf die verfügbaren Alternativen (innerhalb des Produktes) wechselt, statt sich darüber zu ärgern, dass es irgendwas nicht gibt, das man ganz persönlich für unglaublich wichtig hält, der Rest der Welt aber möglicherweise nicht.
Herzlich,
Tom
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von Koverhage »

Hallo Tom,

bequem nicht, habe schon öfters überlegt auf FOX umzustellen, wobei mir der Vorteil
noch nicht so ganz klar ist, außer das ich immer nur eine Indexdatei habe und dafür
nur ein Handle brauche. Ist es deswegen schneller ?

Wie Jan schon sagt, UTF-8 wäre für den Anfang nicht schlecht, gerade wenn man
XML Dateien verarbeiten muss. Da bekomme ich zwar auch schon UTF-16 codierte
XML Dateien, aber das hält sich noch in Grenzen.

SQL wäre eine Option wenn alle Kunden einen Systembetreuer oder Administrator hätten,
die Datenbank muss ja eingerichtet werden, etc. Habe Kunden, denen man sagen muss,
wie man eine Datei als Anhang einer Mail versendet.
Klar gibt es die Möglichkeit die Datenbank per Fernsteuerung zu installieren.
Gruß
Klaus
Benutzeravatar
Herbert
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1991
Registriert: Do, 14. Aug 2008 0:22
Wohnort: Gmunden am Traunsee, Österreich
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von Herbert »

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.
Du kannst DBU unter Xbase compilieren (kleinere Anpassungen) und es geht fast gleich wie das Alte.
Grüsse Herbert
Immer in Bewegung...
Benutzeravatar
azzo
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 483
Registriert: So, 28. Mär 2010 19:21
Danksagung erhalten: 11 Mal

Re: Fragen an Alaska

Beitrag von azzo »

@Tom
Hallo Tom,
ich habe in einem Beitrag über dbf von dir gelesen:
Eindeutige Zähler kann man selbst implementieren.
Hättest du vielleicht ein paar Zeilen Code, wie man das machen kann.
Vielen Dank im voraus.
Gruß
Otto
Benutzeravatar
Armin
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 389
Registriert: Mo, 26. Sep 2005 12:09
Wohnort: 75331 Engelsbrand
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Fragen an Alaska

Beitrag von Armin »

Hallo Tom,
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.
bedeutet das, dass das im neuen WAA funktioniert (vom 1.6.10)?
Auf der Alaska-Seite steht: pdr 4926 closed, Solution:No Workaround for this problem known!
Ich habe das so gelesen, dass der pdr einfach geschlossen wurde - ohne Lösung... :?
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!
Ja, etliches getestet, nix geht
http://www.xbaseforum.de/viewtopic.php? ... &sk=t&sd=a
Zu 6.) Der neue WAA sollte weniger Socket-Error Probleme haben, wir haben hier Korrekturen angebracht.
=D>
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?
Ich weiss, wäre doch schön, wenn das öffentlich wäre - klar kann man auch selber basteln :coffee:

Grüße, Armin
Benutzeravatar
Markus Walter
Programmier-Gott
Programmier-Gott
Beiträge: 1018
Registriert: Di, 24. Jan 2006 10:22
Wohnort: Saarland

Re: Fragen an Alaska

Beitrag von Markus Walter »

azzo hat geschrieben:@Tom
Hallo Tom,
ich habe in einem Beitrag über dbf von dir gelesen:
Eindeutige Zähler kann man selbst implementieren.
Hättest du vielleicht ein paar Zeilen Code, wie man das machen kann.
Vielen Dank im voraus.
Gruß
Otto
Hallo Otto,

kein Code aber ein Hinweis:
Ich habe eine separate DBF mit einem Zählerfeld. Diese wird geöffnet, Satz gesperrt, Wert gelesen, erhöht, geschrieben und geschlossen. Das funktioniert seit Jahren einwandfrei...
Gruß
Markus

Mitglied der XUG Saarland-Pfalz
Antworten