Alternative zu Fox Pro gefunden Erfahrungsbericht
Kuster Peter
einfach viel besser ist. Bei der DEMO, die ich getestet habe, muss man noch
auf dem DOS Prompt arbeiten und einen eingenen Editor verwenden, eben wie
Clipper früher.
Also im jetzigen Entwicklungsstand ist XBase für mich zur Zeit keine
Alternative.
Asche auf mein Haupt für meinen Eintrag vom 16.3.07
Ich bleibe vorerst bei FoxPro und in den nächsten 8 Jahren wird sich schon
etwas ergeben. Ich bin sicher, dass irgend eine Firma sieht was in FoxPro
steckt und kauft MS dieses Produkt wieder ab oder es gibt eine Opensource
Version. Ich habe mich im Netz ein bisschen umgesehen und es gibt auch in
Amerika eine sehr grosse Anhängerschaft von FoxPro.
Wir schauen uns einfach alle um und machen noch ein bisschen Druck auf MS.
Euer
Peter
Holger Vorberg
> Amerika eine sehr grosse Anhängerschaft von FoxPro.
>
> Wir schauen uns einfach alle um und machen noch ein bisschen Druck auf MS.
mit was willst du MS denn unter Druck setzen?
Gemessen an der Zahl der Anwender anderer Entwicklungsumgebungen, sind die
VFP Entwickler eine extrem kleine Zahl. Da wirst du nicht viel Druck erzeugen
können. Auch die vielen VB Entwickler haben keinen Druck auf MS ausüben
können, als MS VB hat sterben lassen.
--
Tschüß,
Holger Vorberg
MS Visual FoxPro MVP
dFPUG Regionalleiter Bielefeld
karl twele
> mit was willst du MS denn unter Druck setzen?
>
> Gemessen an der Zahl der Anwender anderer Entwicklungsumgebungen, sind die
> VFP Entwickler eine extrem kleine Zahl. Da wirst du nicht viel Druck
> erzeugen
> können. Auch die vielen VB Entwickler haben keinen Druck auf MS ausüben
> können, als MS VB hat sterben lassen.
> dFPUG Regionalleiter Bielefeld
Das gute und richtige setzt sich immer durch, das gilt vielfach nur nicht
für MS, leider.
Wer soll Einfluß nehmen, wenn nicht Leute wie du, die ein "MS Visual FoxPro
MVP"
in ihrer Signatur haben. Es gibt ja für MS auch die Möglichkeit VFP auf
eigene Füsse zu stellen und zu einer 100%ige Tochter werden zu lassen.
Foxpro hat ja auch vorher gelebt, bevor MS sie gekauft haben. Wenn eine
solche Tochter selbst entwickeln, werben und verkaufen kann, dann kann das
für MS und seine Betriebssysteme nur von Vorteil sein. Vielleicht können die
MVP´s sich dafür mal stark machen und Ihre Kontakte nutzen.
Gruß KT
Holger Vorberg
> MVP"
> in ihrer Signatur haben. Es gibt ja für MS auch die Möglichkeit VFP auf
> eigene Füsse zu stellen und zu einer 100%ige Tochter werden zu lassen.
> Foxpro hat ja auch vorher gelebt, bevor MS sie gekauft haben. Wenn eine
> solche Tochter selbst entwickeln, werben und verkaufen kann, dann kann das
> für MS und seine Betriebssysteme nur von Vorteil sein. Vielleicht können die
> MVP´s sich dafür mal stark machen und Ihre Kontakte nutzen.
MS hatte letzte Woche alle MVPs (weltweit ca. 4000) nach Seattle eingeladen.
Leider war ich diesmal nicht dort (zwei mal hatte ich aber schon das
Vergnügen). Bei dieser Veranstaltung wurden dann den VFP MVPs bei einem
gesonderten Treffen diese Mitteilung gemacht. Soviel zum Einfluss der MVPs
auf solche Entscheidungen.
Als MS vor Jahren VB6 eingestampft hatte, gab es anschliessend eine Aktion
zahlreicher VB MVPs (und die sind bzw. waren erheblich zahlreicher als VFP
MVPs), die MS dazu veranlassen sollte, das alte VB6 wieder aufleben zu lassen
und es weiter zu entwickeln. Daraus ist bekanntermassen auch nichts geworden.
Die MVPs haben in letzter Zeit viel Einfluss darauf bekommen, wie die
Entwicklung eines Produktes weitergeht, aber nicht ob ein Produkt überhaupt
weiterentwickelt wird.
Kuster Peter
das eingestampft wird.
Ich wechsle auch nicht auf ein MS Produkt.
Das einzige was die verstehen ist, wenn man Sie ignoriert. Wenn das so
weitergeht, dann verkaufen die nur noch Windows, aber nur solange es keine
gute Opensource Alternative gibt.
Euer
Peter
Holger Vorberg
gut, wenns dir egal ist, OK. Dann verstehe die Hintergründe deiner Frage
allerdings nicht.
> Ich schaue mich um und wechsle bestimmt nicht auf .net. Wer weiss wann
> das eingestampft wird.
das weiss keiner. Genauso wenig wie bei jedem anderen Produkt. Egal ob von
MS oder von wem auch immer.
> Ich wechsle auch nicht auf ein MS Produkt.
nun, das sagtest du ja implizit schon damit, dass du nicht auf .NET wechseln
willst. Andere Entwicklungswerkzeuge als VFP und VS.NET gibts von MS ja
nicht. <g>
Boas Enkler
> das weiss keiner. Genauso wenig wie bei jedem anderen Produkt. Egal ob von
> MS oder von wem auch immer.
Wahrscheinlickeit ablesen kann ob ein Produkt noch länger existiert.
Wenn ich mir die Anzahl der .NET Entwickler, den Aufwand den MS in neue
Versionen reinsteckt (aktuell jedes jahr ein weiteres .NET update, für
dieses jahr ist AFAIK schon .net 3.5 angekündigt) und dass selbst MS
Produkte (Biz Talk Server, Office etc...) auf .net technologien wie die
WF aufbauen denke ich dass man sich da schon relativ sicher fühlen kann.
Ich glaube viele lehnen .NET ab weil sie es als "VFP" rivalen halten.
Dabei sehe ich .NET viel mehr als "Partner" von VFP , wodurch es möglich
ist seine VFP Anwendungen länger Visuell modern zu halten und seine VFP
Anwendungen durch .NET Funktionalität zu bereichern.
Da nun ja ein wechsel sich zumindest langfristig anbietet kann man so
auch schon erfahrungen in .NET sammeln
Michael Bickel
Trotzdem wäre eine Alternative schön gewesen, aber wir können es ja
nicht ändern, selbst wenn wir MS für doof halten sowas zu machen... :)
Niemand weiss was in 5 Jahren ist und ob nicht MS von Google, Adobe &
Co überrollt wird, soll ja möglich sein. Kein Imperium, dass noch
nicht zerbrochen ist.
aber inzwischen:
wie sieht es denn mit der Kompatibilität zwischen Net 1.0, 2.0, 3.0
... aus? Ich hab' da nichts gutes gehört, kann es aber nicht selber
beurteilen.
Sowas macht mir auch Bauchweh, bei PHP hat man da ja schon seine
Erfahrungen... bei Foxpro gab es da ja eher selten größere oder echte
Probleme.
Viele Grüße
Michael
--
Michael Bickel
ich habe als Anwender schon 1.0 und 2.0 installiert... geht das dann so
weiter bis die Platte voll ist?
Da frage ich mich schon, wie sieht meine Platte in 5 Jahren aus und
kann / soll ich sowas meinen Anwendern zumuten?
Mir sieht das sehr nach viel Ärger irgendwann aus.
Grüße
Michael
Boas Enkler wrote:
--
Kuster Peter
Zukunft verkaufen wollte. Man lachte mich damals mit Foxpro aus. Alle
wechselten mit dem Argument: Das ist eine Programmiersprache von MS, die
Zukunft ist garantiert. Es hiess damals sogar, dass Teile von Access mit
Visual Basic programmiert worden sind. Mit den genau gleichen Argumenten
will man uns heute .Net verkaufen.
Ich warte mal ab und schaue mir ein paar Sachen an. Habe viele Kollegen die
schon auf etwas gewechselt sind. Werde mal bei denen vorbeischauen und mich
im Internet auf dem Laufenden halten.
Es kommt wie es muss und plötzlich tut sich unverhofft wieder eine Türe auf.
Wie meine Grossmutter, welche zwei Kriege und sonst viel Unbill überlebt hat
immer sagte: Mit Gottvertrauen kommt alles gut.
Euer
Peter
Boas Enkler
> wie sieht es denn mit der Kompatibilität zwischen Net 1.0, 2.0, 3.0
> ... aus? Ich hab' da nichts gutes gehört, kann es aber nicht selber
> beurteilen.
Also als ertes 3.0 ist das .NET Framework 2.0 + Erweiterungsklassen.
Z.bsp. gibts es in 3.0 Klassen für die Workflow Foundation, WPF & WCF
Die Klassen des Cores sind exakt die aus 2.0. Insofern kannst du eine
Anwendung die in 2.0 geschrieben ist problemfrei um optionale Komponente
von 3.0 Erweitern.
Der Schritt von 1.0 auf 2.0 war etwas anders dort wurde tatsächlich der
Kern des .NET Frameworks geändert hier gabs kompatibilitätsprobleme,
weil objekte anders hießen etc. aber diese liesen sich relativ einfach
konvertieren.
Zum Vergleich In VFP gabs auch kompatiblitäts probleme. Z.bsp. im
Verhalten SQL Commandos näher am SQL Standard auszuführen (Group etc...)
weswegen bei vielen firmen noch das Enginebehavior auf 7.0 sitzt.
Upgrades zwischen Versionen ist prinzipiell in jeder Sprache schwierig.
Je nach dem wie der Code aussieht sind diese Dinge aber ganz gut steuerbar.
Da auf den Rechner die Frameworks paralell laufen können kann man ja
aber auch seine Anwendung Stückweise umstellen da man auch module in
verschiedenen Versionen laufen lassen kann. Mit FoxPro wäre das nur
schwierig möglich ;)
Wie gesagt ich finde es auch sehr schade dass VFP eingestellt wurde nur
denke ich sollte man nichts destro trotz die alternativen Objektiv prüfen.
Gerade bei neuen Projekten die eine längere Lebensdauer haben sollen und
auch auf dem "aktuellen Stand" (Unicode,GUI,SOA ??,...) sein sollten
denke ich gibts nur wenig alternativen ausserhalb der .NET Welt
Und ein ganz wichtiger Punkt man kan VFP DLL's aus .NET heraus verwenden
als auch VFPDBMC über OleDb ansprechen.
Holger Vorberg
> weiter bis die Platte voll ist?
hm..., dazwischen gabs aber noch 1.1 <g>
> Da frage ich mich schon, wie sieht meine Platte in 5 Jahren aus und
> kann / soll ich sowas meinen Anwendern zumuten?
Ich versteh das Problem daran nicht. Worin genau besteht hier eine "Zumutung"?
Wenn du Anwendungen mit verschiedenen VFP Versionen entwickelt hast, dann
musstest du ja auch jeweils die richtige Runtime mitliefern. Sicherlich, die
VFP Runtime sind nur ca. 12-15 MB und das .NET Framework so an die 50 MB,
aber das doch wohl nicht wirklich ein Problem, oder?
Man kann sich auch Probleme künstlich einreden.
Michael Bickel
Unser Programm ist kein Individualprogramm, sondern für jeden
zugänglich, da stellen sich schon andere Anforderungen.
Zielgruppe Anwender mit vielleicht 1-20 Benutzer (im Schnitt ca. 5)
Ich kann nicht von jedem erwarten einen SQL-Server zu lizenzieren und
wie würde sich das auf den Preis auswirken....?
Und welche DB sollte ich verwenden? wie gesagt - SQL Server nicht und
sicherlich auch kein Access - habe ich auch gar nicht.
Was anderes habe ich nicht auf Anhieb gesehen. Übergangsweise sollte
dann wenigsten auch Foxpro auftauchen.
Und soll ich jetzt jedes SKIP durch SQL ersetzen?
Ich habe es mir ansatzweise angeschaut und im Moment ist das doch keine
echte Alternative, vielleicht die nächste Version, da habe ich ein
paar Screenshots gesehen, wo man Dinge sieht, die es in Foxpro schon
seit Jahren gibt.
Aber im Moment kann VB .NET doch Foxpro im DB - Bereich nicht
ansatzweise das Wasser reichen.
Für anderes ist es sicherlich flexibler, aber anderes ist nicht mein
Thema im Moment.
Da nützt mir auch eine nette IDE-Verpackung und tolle
Marketingsprüche von MS nichts.
Ich halte die MS Entscheidung einfach nur für Blödsinn, der nur
Ärger macht.
Grüße
Michael
1.1 habe ich auch auf der Platte, 1.0 nicht.
Michael Drechsel
>
> Und soll ich jetzt jedes SKIP durch SQL ersetzen?
>
Hallo,
das genau ist auch mein Problem. Habe mir in den letzten Tagen das
vb.net mal relativ intensiv "angesehen" und viel in den Groups
gelesen.
Auch wenn es vermutlich der "hohen Schule" widerspricht, meine
Programme manipulieren Daten, erzeugen neue statistische Daten etc.
Irgenwie finde ich in den online-Beispielen immer nur: Wie setze ich
ein SQL Statement ab und wie schreibe ich die Daten zurück.
Nun,, das ist wohl keine grosse Kunst. Aber was mach ich auf den
Client mit den Daten ? Nicht mal ein
scan / endscan geschweige denn irgendwelche Cursor scheint es zu
geben. Wird das denn alles in Arrays gehalten ???
Wie funktioniert "seek", "locate". Muss ich das alles selber
organisieren ?
Vielliecht kann man ein vb.net kundiger bisschen was dazu
schreiben ....
Gruss MD
Holger Vorberg
> wie würde sich das auf den Preis auswirken....?
> Und welche DB sollte ich verwenden? wie gesagt - SQL Server nicht und
> sicherlich auch kein Access - habe ich auch gar nicht.
in den letzten Tagen ist hier so viel darüber geschrieben worden, dass man
bei dir den Eindruck bekommt, du würdest die wichtigen Stellen einfach
wegignorieren.
1. wer hat gesagt, dass du einen SQL Server brauchst?
2. es gibt einen SQL Server, der kostenlos ist (SQL Server 2005 Express)
3. geht dein Horizont nicht über SQL Server oder Access hinaus? Du kannst
jede andere Datenbank verwenden, auch eine VFP Datenbank.
> Und soll ich jetzt jedes SKIP durch SQL ersetzen?
Was hat das eine mit dem anderen zu tun?
In VFP bewegst du mit SKIP des Satzzeiger zum nächsten Datensatz.
In .NET gibt es keine Datensätze, somit auch keinen Befehl auf dieser Ebene.
Es gibt in .NET auch keine frei herumfliegenden Cursor. Eine Menge von Daten
wird in einem Objekt (DataTable) abgebildet, wobei die Daten normalerweise
durch ein einmaliges SQL Statement ermittelt werden. In der DataTable gibt es
für jeden "Datensatz" ,jede Spalte und jedes Feld Unterobjekte. Wenn du dich
innerhalb der DataTable bewegen willst, rufst du einfach die passende Methode
dazu auf. Das ist in der Regel auch nur ein Einzeiler.
> Aber im Moment kann VB .NET doch Foxpro im DB - Bereich nicht
> ansatzweise das Wasser reichen.
> Für anderes ist es sicherlich flexibler, aber anderes ist nicht mein
> Thema im Moment.
hast du es mal versucht? Ich bezeweifele es.
Natürlich ist es unter .NET anders, und teilweise etwas umständlicher. Aber
"nicht ansatzweise das Wasser reichen" ist das auf keinen Fall.
Ich bin vor zwei Wochen angefangen, mich in der Firma, bei der ich offiziell
am 01.04. einen neuen Job beginne, einzuarbeiten. Ich habe mich privat in den
letzten Monaten nur mit C# und ASP.NET beschäftigt, werde aber hier in
Zukunft mit VB.NET arbeiten. Und obwohl ich keinerlei VB.NET Praxis hatte,
habe ich hier eine Anwendung damit fast fertiggestellt. Also bitte erzähl
nichts von "nicht ansatzweise das Wasser reichen". Du machst damit nichts
anderes, als das, was jahrelang mit VFP gemacht wurde. Es wurde von
Unwissenden schlecht geredet.
Holger Vorberg
> Client mit den Daten ? Nicht mal ein
> scan / endscan geschweige denn irgendwelche Cursor scheint es zu
> geben. Wird das denn alles in Arrays gehalten ???
Es wird alles in Objekten gehalten.
Das Ergebnis einer SQL Abfrage landet üblicherweise in einem "DataTable"
Objekt.
Eine DataTable hat eine Reihe von Methoden, Eigenschaften und Unterobjekte.
Darunter ist auch eine "Rows" Collection. Die könntest du z.B. mit einer
FOR...EACH Schleife durchscannen. Das wäre quasi das Pendant zu
SCAN...ENDSCAN.
Es gibt eine Reihe weiterer Klasen bzw. Objekte, die dir das Suchen und
Navigieren innerhalb einer DataTable ermöglichen. Das kann man aber hier
nicht alles beschreiben. Ich empfehle dir dazu mal ein Buch zu nehmen, dass
sich mit ADO.NET beschäftigt. Ich habe das auch getan. Gerade das
Datenhandling ist in .NET ein Umfassendes Thema, dass man nicht so im
Vorbeigehen erledigen kann. Wenn man es erst einmal begriffen hat, dann geht
es relativ leicht von der Hand. Wie du wohl schon selber herausgefunden hast,
ist das komplett anders, als bei VFP. In .NET muss man mehr in Objekten und
Klassen denken.
Holger Vorberg
Zum Beispiel das hier:
http://www.edv-buchversand.de/mspress/product.asp?cnt=product&id=ms-589&lng=0
Ich habe die C# Ausgabe davon. Die VB Ausgabe habe ich aber auch bestellt,
liegt nur noch nicht bei mir auf dem Tisch.
Michael Bickel
klar, dass meine Wünsche nicht so viel zählen.
Wir haben ca. 1 Jahr Zeit, hängt ja auch vom weiteren Erfolg unserer
Anwendung ab, aber klar ist, doch dass die Portierung von
zig tausend Zeilen ein Problem ist.
Wenn Orca, oder wie das heißt, kommt - schauen wir es uns an
(natürlich auch andere). Die gegenwärtige Fassung kommt sicherlich
nicht für einen ernsthaften Ersatz in Frage.
Um Erfahrungen zu sammeln, werde ich es aber von Zeit zu Zeit antesten.
VB.Net Express hat mir nur SQL bzw. Access auf Anhieb angeboten... aber
ok, mag sein, dass es irgendwie geht.
Viele Grüße
Michael
Jürgen Nordholz
Hallo Holger,
> VFP Entwickler eine extrem kleine Zahl. Da wirst du nicht viel Druck
> erzeugen
> können. Auch die vielen VB Entwickler haben keinen Druck auf MS ausüben
> können, als MS VB hat sterben lassen.
>
Das kann man wohl so nicht im Raum stehen lassen.
1. Ist es keine kleine Anzahl von Entwicklern bzw. Anwendern!
2. Man kann Visual Basic nicht mit Foxpro vergleichen. Die meisten
Foxpro-Anwendungen haben wesentlich größere Anforderungen und Kunden als
Anwendungen die in Visual Basic laufen.
3. Foxpro ist ein RAD-System für die "Datenbankentwicklung". Diese
Anforderung hat Visual Basic nie erfüllt und dies in .NET umzusetzen ist
Microsoft bis heute nicht gelungen.
MFG
Jürgen
Holger Vorberg
"klein" oder "groß" ist wohl eher relativ. Jedenfalls ist die Anzahl der VFP
Entwickler um ein vielfaches kleiner, als die Zahl der VB Entwickler.
> 2. Man kann Visual Basic nicht mit Foxpro vergleichen. Die meisten
> Foxpro-Anwendungen haben wesentlich größere Anforderungen und Kunden als
> Anwendungen die in Visual Basic laufen.
es ging mir nicht um den Vergleich der beiden Produkte, sondern darum
herauszufinden, wieviel "Druck" man wohl auf MS machen kann. Das ist einer
"großen" VB Gemeinde nicht gelungen und wird noch viel weniger mit einer
vergleichsweise kleinen VFP Gemeinde gelingen. Die VFP Gemeinde ist bei MS
sicherlich berühmt bzw berüchtigt, weil sie viel und oft Kritik geübt und
einen entsprechenden Ruf hat.
Und woher nimmst du die Weisheit, so eine Behauptung über die Anforderungen
und Kunden für "die meisten" Anwendungen aufzustellen? Das ist doch höchstens
Wunschdenken.
> 3. Foxpro ist ein RAD-System für die "Datenbankentwicklung".
Diese Argument hört und liest man immer wieder, aber was genau ist denn
"Datenbankentwicklung" oder eine "Datenbankapplikation"? Wenn man sich in VFP
Entwicklerkreisen umhört, dann ist das wohl eine Disziplin die
ausschliesslich VFP Entwicklern zugeordnet werden kann, weil jede Anwendung,
die nicht mit einem Werkzeug entwickelt wurde, dass neben einer
Programmiersprache auch noch über eine eigene DB Engine verfügt, nicht der
Kategorie "Datenbankapplikation" zugeordnet werden darf. Die Wahrheit ist
aber, dass so gut wie jede Anwendung mit Daten irgendwelcher Art arbeiten
muss, die irgendwo gespeichert sind und Millionen von Entwicklern, die nicht
mit VFP arbeiteten haben das auch gekonnt. Natürlich gibt es in VFP Dinge,
die sehr einfach zu lösen sind und die nur in VFP so funktionieren. Aber
genau das ist der Punkt. In allen anderen Entwicklungsumgebungen werde solche
Dinge eben anders gelöst und die Verbreitung anderer IDEs ist eben größer als
die von VFP.
karl twele
> Bei dieser Veranstaltung wurden dann den VFP MVPs bei einem
> gesonderten Treffen diese Mitteilung gemacht. Soviel zum Einfluss der MVPs
> auf solche Entscheidungen.
Den Raum hätte ich nach ein paar lauten Worten demonstrativ verlassen und
wahrscheinlich wären andere gefolgt, vielleicht sogar alle.
> Als MS vor Jahren VB6 eingestampft hatte, gab es anschliessend eine Aktion
> zahlreicher VB MVPs (und die sind bzw. waren erheblich zahlreicher als VFP
> MVPs), die MS dazu veranlassen sollte, das alte VB6 wieder aufleben zu
> lassen
> und es weiter zu entwickeln. Daraus ist bekanntermassen auch nichts
> geworden.
Ich hab so das Gefühl, du hast deine jahrelange, treue Begleiterin (VFP)
schon verlassen und betrügst sie mit .NET nur weil sie dir jünger und
schöner erscheint. Aber warte mal ab, die will nur dein Geld und deine ganze
Kraft. Irgendwann stehst du da, bist arm, alt, ausgelaugt und denkst an die
gute alte Zeit.
Ich schreibe Anwendungen nur für unser Unternehmen und mein Boss kommt und
möchte eine Liste von allen Gebinden eines Produktes, daß aus einer
Vormaterialcharge entstanden ist. Das dauert mit VFP nicht länger wie 2
Stunden, dann hab ich einen Button in einer bestehenden Maske, eine
SQL-Abfrage und einen Bericht den ich mir betrachten oder Ihn ausdrucken
kann. Glaubst du deine neue Braut kann das auch, ich galube das eher nicht.
Um das mit VB.NET tun zu können muß ich erst einmal 3-4 Monate trainieren
und hab dann nur ein Viertel dessen verstanden, was ich eigentlich über .NET
wissen sollte um dann nochmal 3-4 Monate zu programmieren, damit ich soweit
bin wie heute.
Welchen Vorteil bittet mir .NET in Verbindung mit einer SQLDatenbank,
vielleicht kannst du das beantworten, ich weiß das nicht, außer das ich
weniger Speicher verbrauche wegen der angepassten Stringlängen.
Ein Umsteigen wäre nur dann von Vorteil, wenn die Dinge noch einfacher und
schneller zu realisieren wären wie bei VFP. Was im Hintergrund für das
Erreichen eines Ziels notwendig ist, will ich dabei garnicht wissen.
Gruß KT
Jürgen Nordholz
> Diese Argument hört und liest man immer wieder, aber was genau ist denn
> "Datenbankentwicklung" oder eine "Datenbankapplikation"?
Man kann diesen Begriff durchaus eingrenzen. Spiele oder Systemprogramme
würde ich z. B. nicht als Datenbankapplikation bezeichnen!
> Wenn man sich in VFP
> Entwicklerkreisen umhört, dann ist das wohl eine Disziplin die
> ausschliesslich VFP Entwicklern zugeordnet werden kann, weil jede
> Anwendung,
> die nicht mit einem Werkzeug entwickelt wurde, dass neben einer
> Programmiersprache auch noch über eine eigene DB Engine verfügt, nicht der
> Kategorie "Datenbankapplikation" zugeordnet werden darf.
Ich glaube da solltest Du dich noch einmal umhören! Die meisten kennen auch
XBASE, Filemaker usw.
> Die Wahrheit ist
> aber, dass so gut wie jede Anwendung mit Daten irgendwelcher Art arbeiten
> muss, die irgendwo gespeichert sind und Millionen von Entwicklern, die
> nicht
> mit VFP arbeiteten haben das auch gekonnt. Natürlich gibt es in VFP Dinge,
> die sehr einfach zu lösen sind und die nur in VFP so funktionieren. Aber
> genau das ist der Punkt. In allen anderen Entwicklungsumgebungen werde
> solche
> Dinge eben anders gelöst und die Verbreitung anderer IDEs ist eben größer
> als
> die von VFP.
>
Ich glaube das wissen wir auch. Aber wir reden hier:
1. von Datenbankenapplikationen und
2. von Microsoft
und Microsoft bietet bis heute hierfür keinen ernstzunehmenden Ersatz.
MFG
Jürgen
Holger Vorberg
> wahrscheinlich wären andere gefolgt, vielleicht sogar alle.
möglicherweise haben das einige getan. Ich weiss es nicht, war ja leider
selbst nicht vorort. Vermutlich kam der Zeitpunkt für die meisten
überraschend, aber das Ende von VFP insgesamt eher nicht. Ich selbst hätte
vermutet, dass "Sedna" wohl noch gekommen wäre.
> Ich hab so das Gefühl, du hast deine jahrelange, treue Begleiterin (VFP)
> schon verlassen und betrügst sie mit .NET nur weil sie dir jünger und
> schöner erscheint. Aber warte mal ab, die will nur dein Geld und deine ganze
> Kraft. Irgendwann stehst du da, bist arm, alt, ausgelaugt und denkst an die
> gute alte Zeit.
dein Gefühl trügt dich.
Ich wäre arm (dran) wenn ich mich nicht für .NET (oder was anderes)
entschieden hätte. Im Januar wurde bei meinem letzten Arbeitgeber ein großes
VFP Projekt gestoppt und mir wurde gekündigt. Ich brauchte also ab dem 01.04.
einen neuen Job, und dreimal darfst du raten, was ich im Umkreis von 200Km
nicht gefunden habe. Richtig, einen VFP Job. Es gibt keine, und wenn dann
sind sie gut versteckt. <g> Ich hab mich dann nur auf .NET Jobs beworben, die
zahlreich vorhanden sind und habe auch einen solchen Job bekommen.
> Ich schreibe Anwendungen nur für unser Unternehmen und mein Boss kommt und
> möchte eine Liste von allen Gebinden eines Produktes, daß aus einer
> Vormaterialcharge entstanden ist. Das dauert mit VFP nicht länger wie 2
> Stunden, dann hab ich einen Button in einer bestehenden Maske, eine
> SQL-Abfrage und einen Bericht den ich mir betrachten oder Ihn ausdrucken
> kann. Glaubst du deine neue Braut kann das auch, ich galube das eher nicht.
> Um das mit VB.NET tun zu können muß ich erst einmal 3-4 Monate trainieren
> und hab dann nur ein Viertel dessen verstanden, was ich eigentlich über .NET
> wissen sollte um dann nochmal 3-4 Monate zu programmieren, damit ich soweit
> bin wie heute.
Dafür bräuchte man nicht mal VS.NET, das kannst du interaktiv mit dem SQL
Server und dem SQL Server Management Studio machen. Inclusive eines Reports.
Aber wenns denn wirklich ein Formular werden soll, das hast du in VS.NET
genauso schnell zusammengeklickt wie in VFP. Das Formulieren von SQL Abfragen
musst du in beiden Fällen machen.
Boas Enkler
ich sagen fast mehr für C# als für VB.NET .
In meinem .NET Blog habe ich eine große Link Sammlung (gerade für
einsteiger interessant) zu kostenlosen Ressourcen
s. http://www.BE-IT.NET
Dort findest du auch Sample Codes & Tutorials.
Aktuell arbeite ich an einer Mini Einstiegs Webcast serie nach .NET / C#
falls Themen wünsche bestehen kann ich die da einarbeiten
Möchte auch nochmal Holgers aussage auffassen. Es ist tatäschlich so
dass man in .NET "DatenObjekte" hat. also eine DataTable, DataReader etc...
Man kann z.bsp. mit einem DataReader Sequentiell über Datenrutschen und
es wird immer nur der aktuelel Datensatz geladen, was im Vergleich zu
VFP zu einer enormen netzwerk entlastung führt.
Alle DatenProvider bauen auf einer gemeinsamen schnittstelle auf wodurch
es möglichst ist tatsächlich komplett losgelöst der Datenbank zu
programmieren.
Mann kann auch seine Datenergebnisse (DataTables) als Parameter übergeben...
OleDb bietet auch ein Connection Pooling. Wenn also 2 Anwendungen den
exakt gleichen Connectionstring hat regelt es der OleDb Provider intern
so dass nur eine Connection zum Server offen ist auch das ist ein
angenehmer Nebeneffekt und spart ressourcen.
Wie gesagt man kann mit .NET viel (vermutlich mehr als in VFP) aber es
ist gerade am Anfang auch etwas mehr Aufwand.
Hier mal noch ein paar Webcast links:
[Webcast Finder]
http://www.microsoft.com/germany/msdn/webcasts/finder/default.mspx (Da
gibt es im moment einen cast von VB6 nach VB.NET migrieren)
[MSDN .NET TV]
http://www.microsoft.com/germany/msdn/nettv/default.mspx
Dort gibts u.a. auch Webcast zu ADO.NET
Kostenloses zum Lesen (enthalten auch Infos zu OleDb)
[C# openBook]
http://www.galileocomputing.de/openbook/csharp/
[VB openBook]
http://www.galileocomputing.de/openbook/visual_basic/
Michael Bickel
Foxpro ist dagegen voll auf Daten spezialisiert (auch wenn man
theoretisch auch eine Bildbearbeitung mit schreiben könnte).
und diesen Unterschied merkt man und kann man auch nicht so ohne
weiteres wegdiskutieren....
Da nützt auch Schönreden nix... und abgesehen davon will auch nicht
jeder mit SQL und überhaupt, warum soll das eigentlich wirklich besser
sein?
und vor allem warum auf einmal, weil die MS Typen das erzählen? eine
Fa., dies bis jetzt immer nur das zweitbeste auf den Markt gebracht hat
- wenn überhaupt.
Grüße
Michael
Jürgen Nordholz wrote:
--
Dieter Tautz
Mal eine bescheidene Frage. Ich habe mich auch mal so vorsichtig mit C#
beschäftigt. Was mir aber vollkommen unklar ist - was mache ich mit meinen
vielen Berichten ? Welche Alternative gibt es da ?
Mit besten Grüßen
Dieter
Holger Vorberg
nun, das ist deine ganz persönlich Meinung.
Ich kenne aber eine ganze Reihe von Leuten, die das anders sehen. Und dazu
zähl ich mich selbst auch. Gerade mit der 2005er Version vom VS und SQL
Server ist in meinen Augen ein ernst zu nehmender Ersatz geschaffen worden.
VFP mag sicherlich noch an einigen Stelle die Nase vorn haben, aber wenn
jemand .NET nicht als ernstzunehmenden Ersatz einsetzen kann, dann ist er
daran selber schuld. Ich habe mich jedenfalls bemüht dies zu tun und sehe
keinen Grund, warum andere das nicht auch könnten. Man muss sich halt mal
davon lösen, .NET als Konkurrekten zu VFP zu sehen. Das Problem haben viele
VFP Entwickler, die "ihr" Werkzeug als das einzig wahre betrachten. <g>
Lars
Jeder Autotyp hat eine andere Zielgruppe und warum sollte das bei
Entwicklungsumgebungen nun auf einmal anders sein?
Ist es nicht .. so einfach ist das.
VFP war und ist gerade für kleinere DB Anwendungen eine schnelle,
zuverlässige und kostengünstige Lösung. .NET zielt da sicher etwas
komplexere Strukturen an. Beide haben/hätten Ihre Daseinsberechtigung.
Wem nun .NET nicht passt kann doch auf Delphi wechseln wenn er denn
unbedingt morgen wechslen muss.
Das Delphi 2007 macht mir einen extrem potenten Eindruck und so viel teurer
wie VFP ist es nun auch wieder nicht in der Professional Version. Die hat
zwar keine SQL Schnittstelle, aber das sollte an dieser Stelle ja wohl nicht
stören. Und updaten auf "mit SQL" kann man immernoch (was zugegeben etwas
teuer anmutet).
Klar ist der "Tod" von VFP schade, aber die Welt geht deswegen nun auch
nicht unter.
Keep smiling
Lars
Holger Vorberg
> vielen Berichten ? Welche Alternative gibt es da ?
gute Frage! <g>
In VS.NET ist eine angepasste Version von Crystal Reports mitgeliefert. Ich
hab bisher aber noch nicht die Zeit gefunden, mich damit zu beschäftigen und
kann dir nicht sagen, wie gut die ist. Alternativ dazu gibts natürlich eine
Reihe von Drittanbietertools, wie z.B. List&Label. L&L hätte den Vorteil,
dass es DB und IDE unabhängig ist. Wenn du die Reports deiner VFP Anwendung
mit L&L gemacht hättest, dann könntest du sie in .NET ohne Änderung
weiterverwenden, du müsstest halt nur die gleichen Daten zur Verfügung
stellen.
Michael Bickel
supports the latest versions of SQL databases
hatte ich so verstanden, dass Delphi 2007 SQL unterstützt? aber die
haben ja soviele vers. Versionen... :)
DBX4 sagt mir jetzt nichts, zu lange her, dass ich ernsthaft mit Delpi
gearbeitet habe.
Grüße
Michael
Lars wrote:
--
Lars
> hatte ich so verstanden, dass Delphi 2007 SQL unterstützt? aber die
> haben ja soviele vers. Versionen... :)
> DBX4 sagt mir jetzt nichts, zu lange her, dass ich ernsthaft mit Delpi
> gearbeitet habe.
Hallo Michael,
Professional Edition so 999 EUR ohne SQL
Enterprise Edition so 1999 EUR mit SQL
Unterschiede:
http://www.codegear.com/LinkClick.aspx?fileticket=i0Upr%2fSmdsc%3d&tabid=236&mid=808
Imho ist Delphi gerade in der Enterprise Edition ne super Sache mit WYSIWG
RAD für Webanwendungen, die auch unter Apache laufen inkl. AJAX.
Fazit: Kann viel, sieht vernünftig aus und sollte eine wirkliche Alternative
zu .NET darstellen.
Die nicht so große Verbreitung (davon gehe ich mal aus) macht sich eben im
Preis bemerkbar.
Horst Kühn
weiß garnicht wo ich denn meine Frage mal hinschreiben soll,passt ins
Thema aber auf kein Posting.
Also : mich interessieren mal ganz andere Vergleiche. An die, die sich
mit Dotnet schonmal einigermassen auskennen : Wenn ich mich nun
entschlossen habe zu wechseln: wann sollte ich C# , C++DotNet oder
VB.Net wählen ? Die Vergleiche mit VFP interessieren mich in dem
Zusammenhang garnicht. Welches hätte welche Vor- / Nachteile ?
Ich weiß, da gibs keine eindeutige Aussage zu, aber trotzdem würd ich
gerne mal Argumente für/gegen diese Sprachen kenne
Ciao Horst
Holger Vorberg
> VB.Net wählen ? Die Vergleiche mit VFP interessieren mich in dem
> Zusammenhang garnicht. Welches hätte welche Vor- / Nachteile ?
> Ich weiß, da gibs keine eindeutige Aussage zu, aber trotzdem würd ich
> gerne mal Argumente für/gegen diese Sprachen kenne
tja, das ist im Grunde genommen eine Geschmackssache.
Funktionell gesehen gibt keine Unterschiede. Du kannst in VB das gleiche
machen wie in C#. Ich glaube es gibt bei der Verbreitung einen leichten
Überhang bei C#, du machst aber nichts falsch, wenn du dich mit VB
beschäftigst. Am Ende wirst du vermutlich eh mit beiden Sprachen umgehen
müssen. Die meisten VFP Entwickler die ich kenne, tendieren zu C#, nicht
zuletzt, weil sie auf die Buchstaben "VB" allergisch reagieren. <g> Auch ich
hab mich monate lang mit C# beschäftigt und hab einen Job bekommen, in dem
ich mit VB.NET arbeiten muss, obwohl ich keinerlei Kenntnisse hatte. Die
Sprache ansich ist bei .NET eigentlich auch nur die kleinste Hürde! <g>
Ich empfehle jedem, der sich damit beschäftigen will, mal einen Blick in das
mittlerweile kostenlos erhältliche Buch von Kevin McNeish zu werfen. Titel:
.NET for Visual FoxPro Developers. Kann man von der VFP Webseite
(http:msdn.microsoft.com/vfoxpro) herunterladen. Ich hab das Buch in
gedruckter Form und kann nur sagen, dass das ein Muss für jeden VFP Umsteiger
ist.
Anders Altberg
problemlos.
-Anders
"Michael Bickel" <Michael...@esmb.de> wrote in message
news:OcOo9Bta...@TK2MSFTNGP05.phx.gbl...
Kuster Peter
kann viel. Ausserdem ist es nicht von Microsoft und im Netz gibt es viele
kostenlose Anwendungen, die man übernehmen kann.
Ein Bekannter von mir ist vor Jahren umgestiegen und hat nur gutes berichtet.
Mir ist es sowieso egal, hauptsache nicht Microsoft.
Peter
Jürgen Wondzinski
>> es wird immer nur der aktuelel Datensatz geladen, was im Vergleich zu VFP
>> zu einer enormen netzwerk entlastung führt <<
Immer dieser bescheuerte Unsinn, dass ne VFP-Applikation Unmengen von Daten
zieht, und ADO nicht. Du kannst mit ADO bzw SQLServer genauso ein Netzwerk
dicht machen wie mit VFP. Und du kannst mit VFP mit weniger Datentransport
und 10x schneller nen Einzelsatz lesen als mit SQLServe. Alles nur ne Frage
der Technik und des Wissens.
Die Datenmenge eines Datensatzes ist vollkommen identisch, egal ob du sie
mit ADO oder mit VFP liest. Ein Datensatz hat nun mal eine gleichbleibende
Grösse. Auch das "sequentiell" bringt dir keine Lastreduktion. Auch VFP
"lädt" immer nur den Satz, den du ansteuerst. Und auch ADO verwendet die
Indexdateien, wenn du sie ansprichst.
wOOdy
Wolfgang Malgadey
>
> > Ich hab so das Gefühl, du hast deine jahrelange, treue Begleiterin (VFP)
> > schon verlassen und betrügst sie mit .NET nur weil sie dir jünger und
> > schöner erscheint. Aber warte mal ab, die will nur dein Geld und deine ganze
> > Kraft. Irgendwann stehst du da, bist arm, alt, ausgelaugt und denkst an die
> > gute alte Zeit.
>
> dein Gefühl trügt dich.
> Ich wäre arm (dran) wenn ich mich nicht für .NET (oder was anderes)
> entschieden hätte.
>
> > Stunden, dann hab ich einen Button in einer bestehenden Maske, eine
> > SQL-Abfrage und einen Bericht den ich mir betrachten oder Ihn ausdrucken
> > kann.
>
Holger ich beneide deine Hingabe in dieser NG. Unglaublich wie du hier
ständig gegen diese Windmühlen anrennst :)
Es wird wohl noch etwas dauern, bis die Leute kappieren, dass es nicht
die Sprachen, sondern die Konzepte sind, die Software zu dem machen,
was es ist. "Ein paar" von Menschen definierte Befehle in einer
bestimmten Abfolge. Wie und wem ich diese Befehle mitteile ist
irrelevant. VFP ist ein Mittel zum Zweck, genauso wie JAVA, C#, VB,
PHYTON, RUBY, PHP, ASP, JSP, C++, COBOL, C und wie sie noch alle
heißen.
Völlig richtig, dass ich mich für eine Richtung entscheiden muss. Aber
M$ hat doch gerade den Startschuß für das Ende von VFP gegeben. Warum
also noch länger ärgern? Sucht euch eine, für euer Projekt passende,
Programmierumgebung aus und zerrt nicht länger an Mutties Rockziepfel,
nur weil die Milch so schön warm dort ist.
Man darf sich auch ruhig mal die Finger etwas schmutzig machen, wenn
man etwas im Leben erreichen will.
grüße
Wolfgang Malgadey
Michael Bickel
ja, und schreib mal mir nix dir nix paar tausend zeilen code neu... 114
Forms, zig Reports usw...
Ich mach das noch nicht als Hobby, wo es mal egal ist, was man gerade
nimmt.
Es ist durchaus eine existenzielle Frage, die Zeit für die Umstellung
fehlt ja für die Weiterentwicklung.
Ganz so egal ist es nun nicht...
Ganz nebenbei : stellt eine Fa. ein Produkt wegen Pleite ein - i.O.,
stellt eine Fa. wie MS ein Produkt wie
Foxpro ein - ohne Not - was ganz anderes. Mag jeder über eine solche
Fa. denken, was er will.
Viele Grüße
Michael
--
Michael Bickel
vielleicht - wenn es denn so ist/wäre - ist es auch weniger verbreitet,
weil es so teuer ist... :)
Sie könnten es einem leichter machen...
Die BDE war allerdings einer der Gründe, abgesehen von der Arbeit für
einen Kunden, warum ich irgendwann zu Foxpro gekommen bin
und mich damit angefreundet habe.
Viele Grüße
Michael
Lars wrote:
--
Holger Vorberg
aha, und du findest, dass du mit so einer Einstellung in einer Microsoft
Newsgroup richtig platziert bist. <bg>
Heiko J. Rintelen
Schaut Euch mal diesen Report-Generator und Designer an :
Der ist direkt in Dotnet verwendbar, Open Source, und kann mit Objektlisten
und Tabellendaten umgehen.
Bin auch gerade auf der Suche..
Gruß
Heiko
Tobias Jakobs
"Holger Vorberg" <ei...@die-vorbergs.de> schrieb im Newsbeitrag news:DB4E2ED3-8018-4047...@microsoft.com...
>
> aha, und du findest, dass du mit so einer Einstellung in einer Microsoft
> Newsgroup richtig platziert bist. <bg>
>
Gruß
Tobias
Martin Bauer
VB.Net geht genausso, ist nur ne Einstellung im Menü -> Schwup haste C# Code
oder gern auch umgekehrt :-)
www.sharpdevelop.com
Ich denke nicht das alles was auf .Net läuft auch auf Mono laufen muss ...
sind unterschiedliche Umgebungen.
Halt wie Java-Progies die auch nicht in jeder Java-Runtime laufen und
deshalb schon garnicht auf jeder HW-Plattform.
Dennoch wäre Java ne Alternative zu der Meinung .Net is ok, und Mono gibts
schließlich auch noch. Runtimes aus
unterschiedlichen Häusern die scheinbar das selbe tun, da hab ich so meine
Zweifel.
gRuß Martin
Holger Vorberg
schuld. Wobei ich der Meinung bin nicht "hauptsache nicht Microsoft" sondern
ehr "hauptsache nicht von EINER Firma abhängig sein". Und das geht wenn man
sich z. B. für C# entscheidet ganz gut, da es ja auch neben .NET auch noch
Mono gibt.
hm..., aber du bist nicht von MS unabhängig, wenn du dich für C#
entscheidest. Auch wenn die Entwicklung mit dieser Sprache in anderen IDE als
Visual Studio möglich ist, so ist C# eine Erfindung von MS und die
Spezifikationen werden zum Großteil von MS gemacht. Und Mono versucht ja auch
nichts anderes, als das .NET Framework auf anderen Plattformen verfügbar zu
machen, wobei es immer mind. eine Generation hinter der MS Entwicklung
hinterherhinkt.
Boas Enkler
das hauptproblem ist unamaged Code.
Also wenn du z.bsp. einen manuellen API Call machst, kann mono den
natürlcih nicht wrappen und wenn die Anwendung uaf Linux läuft krachts.
Deswegen wird u.a. empfohlen praktisch nur ,wenn möglich, mit managed
code zu arbeiten.
Zum Thema mono gibts auch einige gute Bücher und Webcasts( einer auch
von der dotnetpro)
Michael Bickel
wegen der widersprüchlichen Angaben auf der Seite edv-buchversand.de
habe ich da mal nachgefragt.
Man kann nun auch bereits von Delphi 1... updaten, es braucht also dann
keine neue Vollversion - vielleicht hast Du dies ja in der Schublade.
Spart immerhin dann so 500 € .
Vielleicht interessant für Dich.
Herzliche Grüße
Michael
Lars wrote:
--
karl twele
> so ist C# eine Erfindung von MS und die
> Spezifikationen werden zum Großteil von MS gemacht.
Erfindung hört sich so an als würde MS, C-Sharp aus dem nichts entwickelt
haben. Es ist wohl mehr eine Weiterentwicklung mit Bestandteilen aus C++,
Java, VB usw. geschrieben für die Verwendung von .NET, ohne bewerten zu
wollen ob das besonders gut oder schlecht gelungen ist.
Erfunden hat MS vielleicht nur, wie man das Wissen anderer zu Geld macht und
mich ägert in erster Linie daran, daß ich da vor vielen Jahren nicht selbst
drauf gekommen bin.
Gruß KT
Tobias Jakobs
Tobias
Tobias Jakobs
> Ich denke nicht das alles was auf .Net läuft auch auf Mono laufen muss ...
> sind unterschiedliche Umgebungen.
MfG
Tobias
Holger Vorberg
des Frameworks. Wenn also MS, wie jetzt bei Foxpro, keine Lust mehr hat es
weiterzuentwickeln gibt es noch die Möglichkeit Mono zu benutzen
ja, da hast du recht. Diese Möglichkeit würde dann bestehen.
Ich bin mir allerdings ziemlich sicher, dass MS nicht so schnell die Lust an
der Weiterentwicklung des Frameworks vergeht. Immerhin ist es mittlerweile
bei MS Basis für wichtige, wenn nicht sogar die wichtigsten strategische
Produkte. Das wäre also ein Schuss in den eigenen Fuß, der selbst MS nicht
zuzutrauen wäre.
Lars
"Michael Bickel" <Michael...@esmb.de> schrieb im Newsbeitrag
news:e8qE$s6aHH...@TK2MSFTNGP04.phx.gbl...
> Hallo Lars,
>
> wegen der widersprüchlichen Angaben auf der Seite edv-buchversand.de
> habe ich da mal nachgefragt.
>
> Man kann nun auch bereits von Delphi 1... updaten, es braucht also dann
> keine neue Vollversion - vielleicht hast Du dies ja in der Schublade.
Hi Michael,
danke .. und falls nicht, kauft man irgendwo gebraucht n billiges.
Das ist nicht das Problem.
Ich selbst hab .NET eh hier .. also weshalb auch noch Delphi?
Meine aktuellen Fox Projekte mach ich bis Releasequalität eh im Fuchs fertig
und werd mir dann mal die ersten Teile auf C# und PostgreSQL umbauen um das
zu testen. Aber das frühestens 2008/2009.
Mir taugt der Fuchs noch n paar Jahre .. solange der Vista unterstütz hab
ich erstmal keinen Stress.
Gruß
Lars
Wolfgang Malgadey
> > Es wird wohl noch etwas dauern, bis die Leute kappieren, dass es nicht
> > die Sprachen, sondern die Konzepte sind, die Software zu dem machen,
> > was sie ist.
>
> > Völlig richtig, dass ich mich für eine Richtung entscheiden muss.
> > [...]
> > Man darf sich auch ruhig mal die Finger etwas schmutzig machen, wenn
> > man etwas im Leben erreichen will.
>
> ja, und schreib mal mir nix dir nix paar tausend zeilen code neu... 114
> Forms, zig Reports usw...
> [...]
> Es ist durchaus eine existenzielle Frage, die Zeit für die Umstellung
> fehlt ja für die Weiterentwicklung.
> Ganz so egal ist es nun nicht...
Stimmt MS hinterherzulaufen, damit eine mehr schlecht als recht
entwickelte IDE noch ein paar mehr Lebensjahre eingehaucht bekommt
macht auch viel mehr Sinn. Und am Besten VFP weiterentwickeln.
Vielleicht ein wenig .net rein? oder eher doch was ganz anderes und
weiter das eigene VFPSüppchen kochen?
Es gibt doch kaum bessere Gelegenheiten eine Neustrukturierung zu
beginnen. Kannst ja nur froh sein, dass du den Code schonmal
geschrieben hast. Da dauert die Entwicklung garantiert nicht so lang
wie beim ersten mal :)
> Ganz nebenbei : stellt eine Fa. ein Produkt wegen Pleite ein - i.O.,
> stellt eine Fa. wie MS ein Produkt wie
> Foxpro ein - ohne Not - was ganz anderes. Mag jeder über eine solche
> Fa. denken, was er will.
Von mir aus kann MS seine Produkte einstampfen wie und wann es will.
Mal sehen was mein Steuerberater sagt, wenn ich ihm erzähle, dass MS
doch tatsächlich mein einziges Standbein abgesägt hat. Der wird mich
bestimmt trösten und die nächsten 20 Jahre finanziell unterstützen.
Vielleicht kramt er ja auch die NG Posts von vor 10 (8; 5; 3; 2; 1)
Jahren aus. Da gab es ja solche Diskussionen über VFP des Öfteren. Nur
gab es dazu keine definierte Aussage seitens der Publisher. Vielleicht
zeigt er mir aber auch einfach seine Adressverwaltung in VFP6 und
beweißt mir, dass die ja heute läuft wie vor 5 Jahren. Und leider
genauso aussieht.
MS hat sein Monopol ja nicht von heut auf morgen erbaut. Ständig wird
darüber gesprochen, dass MS Software nicht brauchbar ist (.net wurde
zu beginn beschimpft, xp wurde zu beginn beschimpft, vista wird
beschimpft, liste mit weiteren MS Produkten fortführen), aber keiner
wagt den Schritt in eine neue Richtung. Ich bleibe lieber flexibel und
halte mir alle wege offen.
Ich verwende eine Sprache, bis mir die durch sie gegebenen Lösungswege
ausgehen. Und das ist bei mir mit VFP schon längst erreicht. Es bleibt
weiterhin ein nettes RAD-Tool. Mehr eher nicht...
So long
Wolfgang Malgadey
Michael Bickel
aber heute auf einmal schrecklich altmodisch ist.
Man kann auch bewährtes Weiterentwickeln, warum Neues immer beser sein
soll, entzieht sich meiner Kenntniss.
Entspricht aber wohl dem Zeitgeist, wo ja nichts wirklich mehr zählt
ausser oberflächliche Marketingsprüche, dies am besten in englisch,
damit es weniger dämlich klingt...
Grüße
Michael
Wolfgang Malgadey wrote:
--
Holger Vorberg
> aber heute auf einmal schrecklich altmodisch ist.
>
> Man kann auch bewährtes Weiterentwickeln, warum Neues immer beser sein
> soll, entzieht sich meiner Kenntniss.
mir ist irgendwie unklar, auf wen oder was du dich damit beziehst, vor allem
weil du die gesamte vorangegangene Message nebst der darin enthaltenen Zitate
hier erneut zitiert hast.
Nur ist VFP für manche nicht "auf einmal" schrecklich altmodisch. Das hat
sich über Jahre so entwickelt und ist auch über diesen Zeitraum immer wieder
mal kritisiert worden, auch von mir. Wer die Welt hinter dem VFP Tellerrand
im Auge behalten hat, der dürfte gemerkt haben, dass neuere Technologische
Entwicklungen bei MS in erster Linie bei .NET Einzug erhalten haben. Darunter
waren viele Dinge, die sich VFP Entwickler lange Zeit gewünscht haben.
Irgendwann kommt der Punkt, wo man als VFP Entwickler dann einfach
resigniert. Bei mir war das nicht kürzlich der Fall. Ich habe das Ende von
VFP nach Version 7 kommen sehen.
Michael Bickel
Alternativen braucht, obwohl man mit der aktuellen Version durchaus
moderne Anwendungen (auch optisch) schreiben kann.
Ich meine nur, dass es nicht so hätte sein müssen.
So wie aus VB VB.NET wurde, hätte auch Foxpro weiterentwickelt werden
können, man muss dazu nicht
unbedingt was Neues haben.
Aber es ist, wie es ist, daher
eine ernsthafte Frage:
Unsere Anwendung basiert auf dbf-Tabellen, diese können irgendwo
installiert sein, an einem zentralen Platz also.
Die diversen Installationen auf vers. Rechnern greifen dann eben auf
diese Daten zu, klappt auch gut.
Man kann davon ausgehen (im Moment), dass so das Maximum 20
Installationen sind.
Frage:
welche Versionen von VB.NET, SQL-Server bräuchte man den tatsächlich
dafür? um ungefähr das gleiche zu realisieren (vom Aufbau, nicht
unbedingt technisch).
Die div. Express-Versionen sind ja doch sicherlich irgendwo
eingeschränkt. Reicht da SQL Express? Oder erlaubt dieser nur Zugriffe
von dem Rechner, auf dem er installiert ist?
Viele Grüße
Michael
Holger Vorberg
>
> welche Versionen von VB.NET, SQL-Server bräuchte man den tatsächlich
> dafür? um ungefähr das gleiche zu realisieren (vom Aufbau, nicht
> unbedingt technisch).
>
> Die div. Express-Versionen sind ja doch sicherlich irgendwo
> eingeschränkt. Reicht da SQL Express? Oder erlaubt dieser nur Zugriffe
> von dem Rechner, auf dem er installiert ist?
es sollte erstmal mit den Express Versionen lösbar sein.
Aber du musst ja nicht zwangsweise auf SQL Server umsteigen. Du kannst
genausogut mit der vorhandenen VFP Datenbank arbeiten. .NET bietet
verschiedene Zugriffsprovider an. Darunter auch einen für OLEDB Datenquellen.
Und da es für VFP einen aktuellen OLE DB Treiber gibt, geht das problemlos.
Der SQL Server Express ist auch auf einem Server installierbar. Bei der
Installation ist aber per Default das TCP/IP Protokoll deaktiviert. Das musst
du dann nachträglich aktivieren, dann funktioniert auch der Zugriff vom
Client auf den Server.
Lars
Hallöchen,
das Problem ist hierbei einfach folgende:
Ein SQL Server kostet einen Server recht viel an Performance.
Nimm einen aktuellen MSSql, der ist empfohlener Weise auf Servern mit 2GB
Ram, sehr fixen Platten und so ca.3GHz Xeon i.O.
Klar funktioniert er auch mit kleineren Servern, aber hier sind dann einfach
Performanceprobleme bei Peaks zu erwarten, da eben der SQL Server die (fast)
ganze Datenaufbereitung übernimmt und nicht wie bei dbx die Rechenlast auf
die Clients verteilt wird.
Das ist immernoch mein Hauptaugenmerk bei der Datenbankwahl. (Ich kenn meine
Kunden und da ist es eben nicht mal so einfach einen zusätzlichen Server nur
für SQL zu stellen).
Wir reden hier im Endeffekt über die Endkosten, die ein Softwareprodukt
verursacht.
Und die sind bei einer SQL Client/Server Applikation für den Kunden in
vielen Fällen einfach höher, wie bei einer VFP, Delphi oder sonstwas Lösung.
Das Argument der .NET mit VFP Datenbanken lasse ich hierbei mal aussen vor.
Wenn man die Tabellen eh noch mit FoxPro macht, kann man ja gleich die ganze
Anwendung auf VFP lassen. Ich denke die Diskussion dreht sich doch eher um
eine komplette Ablöse / Alternative zum Füchslein :)
Grüße
Lars
Michael Bickel
i.d. Tat gehe ich davon aus, dass die typischen Kunden
a. kein extra Geld für Server in Form von Hard- oder Software ausgeben
werden
b. eher wenig technisches Verständnis haben
De facto wäre es extrem nachteilig zusätzliche Kosten auf die Lizenzen
draufschlagen zu müssen, nur weil eine spezielle Zusatzsoftware
notwendig wäre.
Von daher wäre es ein Muß, dann man wenigstens eine kostenlose
Express-Version ausliefern kann und dass diese in vernünftigen Maß
mit 5, vielleicht max 20 Anwendern, die gleichzeitig auf die Daten
zugreifen könnten (20 eher nicht die Regel, aber es müßte es aushalten
können)
umgehen kann.
Sonst wäre es einfach nicht anwendungsfähig, was dann aber sicher für
sehr viele Anwendungen gelten würde.
Delphi+irgendein SQL ergebe vermutlich die gleichen Probleme wie
.NET/SQL.
Viele Grüße
Michael
--
Lars
>
> i.d. Tat gehe ich davon aus, dass die typischen Kunden
>
> a. kein extra Geld für Server in Form von Hard- oder Software ausgeben
> werden
> b. eher wenig technisches Verständnis haben
>
> De facto wäre es extrem nachteilig zusätzliche Kosten auf die Lizenzen
> draufschlagen zu müssen, nur weil eine spezielle Zusatzsoftware
> notwendig wäre.
> Von daher wäre es ein Muß, dann man wenigstens eine kostenlose
> Express-Version ausliefern kann und dass diese in vernünftigen Maß
> mit 5, vielleicht max 20 Anwendern, die gleichzeitig auf die Daten
> zugreifen könnten (20 eher nicht die Regel, aber es müßte es aushalten
> können)
> umgehen kann.
>
> Sonst wäre es einfach nicht anwendungsfähig, was dann aber sicher für
> sehr viele Anwendungen gelten würde.
> Delphi+irgendein SQL ergebe vermutlich die gleichen Probleme wie
> .NET/SQL.
>
> Viele Grüße
> Michael
Hallo Michael,
Delphi arbeitet äquivalent VFP mit DBx Datenbanken.
Du brauchst also "keinen" zusätzlichen hochperformanten Server dafür, es
reicht wie bis dato der eh vorhandene Fileserver oder zur Not ne kleine
NAS/SAN Lösung. Somit hätte man mit Delphi eine wirkliche Alternative zu
VFP.
Ansonsten: Nimm PostgreSQL.
Version 8.2 is raus und kosten tut das auch nix. Wenn ich auf .NET umstelle
werde ich auch den PostgreSQL nehmen, da ich irgendwelche nicht managebaren
oder verbindungslimitierten Lösungen ablehne. Es kommt einfach blöde beim
Kunden zu stehen und sagen zu müssen .. ja ne .. tut mir leid, aber wenn wir
den Herrn Müller noch anbinden wollen müssens erstmal paar Tausend Euro
Lizenzgebühren nu locker machen.
Dann lieber gleich nen vollwertigen freien SQL Server und gut is. Da gibts
dann wenigstens keine Kostenfallen.
Gruß
Lars
Boas Enkler
> Klar funktioniert er auch mit kleineren Servern, aber hier sind dann
einfach
> Performanceprobleme bei Peaks zu erwarten, da eben der SQL Server die
(fast)
> ganze Datenaufbereitung übernimmt und nicht wie bei dbx die
Rechenlast auf
> die Clients verteilt wird.
AFAIk kannst du in .NET die Datenbank dateien auch filebasiert also ohne
laufenden SQL Server Service ansprechen.
ob und wenn ja mit welchen einschränkungen man leben muss weiß ich nicht
. Werde mal die augen offen halten ;)
Michael Bickel
ich habe es mir natürlich runtergeladen. das würde das Leben schon
erleichtern.
Einzige Frage, die ich mir noch stelle, ist die der Distribution bzw.
Konfiguration auf Kundenseite und wieweit dies sich alles
automatisieren lässt - aber da werde ich mich schon durchfinden.
Viele Grüße
Michael
Lars wrote:
>
> Hallo Michael,
>
> Delphi arbeitet äquivalent VFP mit DBx Datenbanken.
> Du brauchst also "keinen" zusätzlichen hochperformanten Server dafür,
> es reicht wie bis dato der eh vorhandene Fileserver oder zur Not ne
> kleine NAS/SAN Lösung. Somit hätte man mit Delphi eine wirkliche
> Alternative zu VFP. Ansonsten: Nimm PostgreSQL. Version 8.2 is raus
> und kosten tut das auch nix. Wenn ich auf .NET umstelle werde ich
> auch den PostgreSQL nehmen, da ich irgendwelche nicht managebaren
> oder verbindungslimitierten Lösungen ablehne. Es kommt einfach blöde
> beim Kunden zu stehen und sagen zu müssen .. ja ne .. tut mir leid,
> aber wenn wir den Herrn Müller noch anbinden wollen müssens erstmal
> paar Tausend Euro Lizenzgebühren nu locker machen. Dann lieber
> gleich nen vollwertigen freien SQL Server und gut is. Da gibts dann
> wenigstens keine Kostenfallen.
>
> Gruß
>
> Lars
--
Bernhard Sander
> > Klar funktioniert er auch mit kleineren Servern, aber hier sind dann
> einfach
> > Performanceprobleme bei Peaks zu erwarten, da eben der SQL Server die
> (fast)
> > ganze Datenaufbereitung übernimmt und nicht wie bei dbx die
> Rechenlast auf
> > die Clients verteilt wird.
>
> AFAIk kannst du in .NET die Datenbank dateien auch filebasiert also ohne
> laufenden SQL Server Service ansprechen.
Mit so ziemlich jeder Programmiersprache kann man filebasierte Datenbanken
ansprechen. sowas wie fopen kennt jede, es heißt im einzelnen vielleicht anders.
Das DBF-Format dokumentiert sich selber. Das kann auch jede Programmiersprache,
die die Datei aufbekommt, auslesen und weiß nachher, wo sie hinfassen muss, wenn
ein bestimmtes Datenpäckchen angesprochen wird.
Bis man aber zu dem Komfort von
USE ...
SET FILTER TO ...
SET ORDER TO ...
SCAN ... ENDSCAN
usw vorgedrungen ist, das macht den wesentlichen Unterschied zwischen Foxpro und
Konsorten auf der einen Seite und einer beliebigen Programmiersprache auf der
anderen Seite aus.
Mein Eindruck: Wo man sich mit allgemeineren Programmiersprachen leichter tut,
das ist, wenn man mit GUI-Elementen von Foxpro nicht zufrieden ist. Da kommt man
mit den allgemeineren Programmiersprachen tiefer rein.
Gruß
Bernhard Sander
Wolfgang Malgadey
Es gibt genügend Datenbanksysteme die mit diversen Methoden in .NET
Sprachen eingebaut werden können. Kommerziele wie Freie. Dabei ist es
nur zweitrangig ob das System ODBC, ADO oder OLE DB beherrscht. Aber
es ist eine Brücke!
Das selbe gilt für JAVA und DELPHI. Um die Anbindung von Datenbanken
wird sich wohl heutzutage die meisten Gedanken gemacht :)
Die Wahl der Datenbank ist mit nichten unerheblich. Aber die Wahl ist
wohl ähnlich prophetisch wie die der Programmierumgebung.
On 23 Mrz., 11:44, Bernhard Sander <f...@no.spam> wrote:
> > AFAIk kannst du in .NET die Datenbank dateien auch filebasiert also ohne
> > laufenden SQL Server Service ansprechen.
>
> [...]
> Bis man aber zu dem Komfort von
> USE ...
> SET FILTER TO ...
> SET ORDER TO ...
> SCAN ... ENDSCAN
> usw vorgedrungen ist, das macht den wesentlichen Unterschied zwischen Foxpro und
> Konsorten auf der einen Seite und einer beliebigen Programmiersprache auf der
> anderen Seite aus.
Nenne mir bitte 1nen wirklichen Vorteil auf Daten mit solch
unkontrollierbaren Funktionen zugreifen zu können? Wieso reden alle
von "Business Objects", wenn eh jeder auf die Rohdaten zugreifen kann
(und dies tun wird)? VFP ist eine schnelle, leichtfüßige Umgebung, in
der so mancher Schatz entstanden ist. Aber es ist nur mit viel
Sorgfalt möglich so sicheren Code zu erzeugen, dass dieser auch nach
der 10ten Bearbeitung noch 100%ig läuft.
Ein Beispiel?
Wir nutzen ein Grid (wir nutzen viele Grids) das seit ca. 3 Monaten
gut lief. Nach einer kleinen Änderung -ich habe in einem Cursoradapter
eine weitere Datenquelle geöffnet und damit ein paar Operationen
durchgeführt- muckte auf einmal dieses Grid rum. Warum? Der
Cursoradapter hatte mit dem Grid eigentlich nix zu tun.
Gaaaanz einfach (hat mich ca 4h gekostet). Ich habe in meiner
Veränderung einen anderen Alias Selectiert (SELECT andererAlias) und
vergessen das obligatorische lnOld = SELECT() und SELECT (lnOld)
einzubauen. Dadurch lief eine etwas unsauber gefüllt Eigenschaft (ich
glaube ein controlsource) in einen ERROR. Ich hatte in der
Controlsource doch tatsächlich vergessen den Alias der zu verwendeten
Eigenschaft anzugeben. TADAA *Selfmadeerror* WTF?
Und davon gibt es noch genug andere Schätze.
Es ist immer ein Vorteil schnell und einfach Entwickeln zu können.
Wenn das aber auf Kosten der Wartbarkeit geht bringt mir die
anfängliche Leichtigkeit nix. Ich versuche ständig das Verhalten von
VFP auszubessern, anstatt meine Probleme zu lösen.
Wolfgang Malgadey
<DieterTa...@discussions.microsoft.com> wrote:
> Hallo Holger.
>
> Mal eine bescheidene Frage. Ich habe mich auch mal so vorsichtig mit C#
> beschäftigt. Was mir aber vollkommen unklar ist - was mache ich mit meinen
> vielen Berichten ? Welche Alternative gibt es da ?
combit List&Label ist gut in .NET intergrierbar. Wir nutzen es zur
Zeit für diverse Reports aus VFP heraus (Dank der direkten RTF
unterstützung).
Crystal Reports ist auch prima in .NET integrierbar. Es hat eigentlich
"weniger" mit .NET direkt zu tun. Die SQL Befehle können direkt im
Report eingegeben werden. Persönliche Hassgefühle gegen diese Software
verbieten mir leider den Umgang damit.
http://jasperforge.org/sf/projects/jasperreports
Jasperreports ist ein Reportsystem für JAVA und Microsoft nutz z.B. im
Dynamics CRM die SQL Reporting Services des SQL Servers.
Starten kann man auf jedenfall hier (http://del.icio.us/tag/reporting)
wenn man kein Google möchte :)
Grüße
Wolfgang Malgadey
Bernhard Sander
>>[...]
>>Bis man aber zu dem Komfort von
>>USE ...
>>SET FILTER TO ...
>>SET ORDER TO ...
>>SCAN ... ENDSCAN
>>usw vorgedrungen ist, das macht den wesentlichen Unterschied zwischen Foxpro und
>>Konsorten auf der einen Seite und einer beliebigen Programmiersprache auf der
>>anderen Seite aus.
>
>
> Nenne mir bitte 1nen wirklichen Vorteil auf Daten mit solch
> unkontrollierbaren Funktionen zugreifen zu können? Wieso reden alle
> von "Business Objects", wenn eh jeder auf die Rohdaten zugreifen kann
> (und dies tun wird)? VFP ist eine schnelle, leichtfüßige Umgebung, in
> der so mancher Schatz entstanden ist. Aber es ist nur mit viel
> Sorgfalt möglich so sicheren Code zu erzeugen, dass dieser auch nach
> der 10ten Bearbeitung noch 100%ig läuft.
Da liegt das Problem.
Foxpro bildet die Grenze zwischen leichtfüßigem und schwerwiegendem System (mir
fallen keine besseren Ausdrücke ein). Ich denke, bis wenige 10 Benutzer ist
(war) Foxpro sehr gut brauchbar, drüber hinaus sollte man sehr wohl über
ausgefeiltere (stabilere) Systeme nachdenken. Foxpro (wie grundsätzlich das
System dBase) ist gerade für den unteren Rand ziemlich gut brauchbar, da man mit
dem Befehlsfenster einen hervorragenden Zugriff auf die Daten hat. Es ist vor
allem auch gut brauchbar für Leute, die nicht die ausgefuchsten
Programmierprofis sind. Bei einfachen Aufgaben braucht man auch eher keine
Geschäftsobjekte.
Ich weiß auch noch nicht so genau, ob ich eher weinen oder lachen soll, dass
Foxpro nun beerdigt wird. Aber auch Tränen werden nicht darüber weghelfen, dass
die Situation so ist, wie sie ist.
Bezüglich der Sicherheit nach der 10. Bearbeitung: da würde ich bei keiner
Programmiersprache auf irgendwas wetten. Dazu sind die Programmierer alle viel
zu wenig begeisterte Literaten um die Doku für sauberes Nachvollziehen der
gewählten Vorgehensweise anzulegen oder gar auf dem Stand zu halten.
Guten Blick nach vorn
Bernhard Sander
Alfred Langer
<h.k...@freenet.de> wrote:
>Hach Mensch Leute,
>
>weiß garnicht wo ich denn meine Frage mal hinschreiben soll,passt ins
>Thema aber auf kein Posting.
>Also : mich interessieren mal ganz andere Vergleiche. An die, die sich
>mit Dotnet schonmal einigermassen auskennen : Wenn ich mich nun
>entschlossen habe zu wechseln: wann sollte ich C# , C++DotNet oder
>VB.Net wählen ? Die Vergleiche mit VFP interessieren mich in dem
>Zusammenhang garnicht. Welches hätte welche Vor- / Nachteile ?
>Ich weiß, da gibs keine eindeutige Aussage zu, aber trotzdem würd ich
>gerne mal Argumente für/gegen diese Sprachen kenne
>
>Ciao Horst
Hallo Horst,
ich kann dir aus meiner Sicht nur sagen, dass .Net in meinen Augen
einen ganz entscheidenden Mangel hat, nämlich das Grundkonzept.
Der Client arbeitet mit einer Kopie der Datenbank und der
Programmierer kann sich mit dem Update der Datenbank herum-
schlagen. Für mich Steinzeit.
Versuche folgende simple Anwendung. Maske und Daten erfassen.
Wenn man Foxpro oder Access gewöhnt ist man nur noch beeindruckt.
Gruß Alfred
Holger Vorberg
> ich kann dir aus meiner Sicht nur sagen, dass .Net in meinen Augen
> einen ganz entscheidenden Mangel hat, nämlich das Grundkonzept.
Wenn etwas beim .NET sofort ins Auge sticht, dann ist es das Konzept. Mir ist absolut schleierhaft,
wie du auf die Idee kommst, es würde an einem Grundkonzept mangeln.
> Der Client arbeitet mit einer Kopie der Datenbank und der
> Programmierer kann sich mit dem Update der Datenbank herum-
> schlagen. Für mich Steinzeit.
hä...? Sorry, aber das ist totaler Quatsch.
Ich weiss nicht von welchem .NET du redest, aber bestimmt nicht von Microsoft Visual Studio .NET.
Entweder hast du das selbst nie ausprobiert und/oder du hast etwas grundlegend missverstanden.
> Versuche folgende simple Anwendung. Maske und Daten erfassen.
ich würde sagen, dass hast du dir in VS.NET in wenigen Minuten zusammengeklickt und musstest keine
Zeile Code schreiben.
alfred...@t-online.de
Holger Vorberg <ei...@die-vorbergs.de> wrote:
> Hi,
>
> > ich kann dir aus meiner Sicht nur sagen, dass .Net in meinen Augen
> > einen ganz entscheidenden Mangel hat, nämlich das Grundkonzept.
>
> Wenn etwas beim .NET sofort ins Auge sticht, dann ist es das Konzept. Mir ist absolut schleierhaft,
> wie du auf die Idee kommst, es würde an einem Grundkonzept mangeln.
>
> > Der Client arbeitet mit einer Kopie der Datenbank und der
> > Programmierer kann sich mit dem Update der Datenbank herum-
> > schlagen. Für mich Steinzeit.
>
> hä...? Sorry, aber das ist totaler Quatsch.
> Ich weiss nicht von welchem .NET du redest, aber bestimmt nicht von Microsoft Visual Studio .NET.
> Entweder hast du das selbst nie ausprobiert und/oder du hast etwas grundlegend missverstanden.
Ausprobiert mit Visual Studio Express(Wollte wissen ob
ein update von Visual Studio 2003 Sinn macht).
Ich denke ich habe es schon richtig verstanden.
Auf dem Client wird eine Kopie der Datenbank abgelegt.
Werden Daten geändert, werden diese zunächst nur in der Kopie auf dem Client geändert. Erst beim explizieten update wird die Datenbank geändert.
>
> > Versuche folgende simple Anwendung. Maske und Daten erfassen.
>
> ich würde sagen, dass hast du dir in VS.NET in wenigen Minuten zusammengeklickt und musstest keine
> Zeile Code schreiben.
So einfach habe ich es mir nicht gemacht. Ich hab das alles schon wieder verdrängt, weil ich mich so über den
Zeitverlust geärgert habe. Aber ich suche dass nochmal
raus und beschreibe die Problematik an einem Beispiel.
Gruß Alfred
Michael Bickel
was mir sofort aufgefallen ist:
Label auf Picturebox, versucht Hintergrund transparent zu machen -
klappt nicht.
(man musste dem Label erst mitteilen, dass er auf einer Picturebox
sitzt).
Musste ich erst 2 Zeilen Code dafür einsetzen - sowas habe ich seit
mindestens 10 Jahren nicht mehr gesehen, sowohl bei Delphi als auch
Foxpro langt da ein Klick.
Das Anpassen des Grid-Moduls (z.B. Spaltenbreite) finde ich altmodisch
- nix visuell? oder habe ich das übersehen? Bei Foxpro doch erheblich
einfacher.
Ich bin noch nicht weit genug für eine abschließende Entscheidung -
aber vieles erscheint mir unnötig kompliziert und eher rückschrittlich.
Ich habe mal das Arbeiten mit Elementen, ziehen, vergrößern... etc. mit
Foxpro und Delphi verglichen. Mein Gott, was für ein Unterschied.
Ich weiss, das macht nicht alles an einer Sprache aus, aber auch das
ist wichtig. Und irgendwie erscheint mir so langsam Foxpro als gar
nicht so altmodisch mehr.
Und Leichtigkeit muss nichts bedenkliches sein....
Aber ich werde es weiter testen... Voreingenommen wie ich bin :) habe
ich aber schon jetzt wieder das gleiche Gefühl wie vor 10 Jahren...
(mit Ausnahme von Foxpro natürlich)
--
Viele Grüße
Michael
alfred...@t-online.de
Auch alternative Grids sind nicht leider auch nicht besser.
> - nix visuell? oder habe ich das übersehen? Bei Foxpro doch erheblich
> einfacher.
> Ich bin noch nicht weit genug für eine abschließende Entscheidung -
> aber vieles erscheint mir unnötig kompliziert und eher rückschrittlich.
dem kann ich mich nur anschließen
> Ich habe mal das Arbeiten mit Elementen, ziehen, vergrößern... etc. mit
> Foxpro und Delphi verglichen. Mein Gott, was für ein Unterschied.
> Ich weiss, das macht nicht alles an einer Sprache aus, aber auch das
> ist wichtig. Und irgendwie erscheint mir so langsam Foxpro als gar
> nicht so altmodisch mehr.
Hab ein gepatchtes Foxpro 2.6 unter XP am laufen um eine alte Anwendung nicht zu verlieren. Es ist für mich immer noch das Tool mit dem ich gerne arbeite und ich habe schon mit einigen Programmen(dbase, visualdbase, greeleaf, pardox, visual studio 6.0, Visual studio .net 2002; access 2002; alaska) programmiert.
> Und Leichtigkeit muss nichts bedenkliches sein....
>
> Aber ich werde es weiter testen... Voreingenommen wie ich bin :) habe
> ich aber schon jetzt wieder das gleiche Gefühl wie vor 10 Jahren...
> (mit Ausnahme von Foxpro natürlich)
>
> Viele Grüße
> Michael
Gruß Alfred
Heiko J. Rintelen
Hab da was aus der XBase-Welt für Dotnet gefunden :
http://vulcandotnet.com/index.html
Ist eine Entwicklung für Visual Objects Programmierer die in Dotnet
weitermachen
wollen. Kenn mich nicht so mit Visual Objects aus, war damals aber auch ein
möglicher Kandidat für ein Entwicklungssystem. Ich weiß nicht wie weit weg
VO
von FOX ist, in jedem Fall wird XBase in Dotnet weiterleben....
Gruß
Heiko
"Kuster Peter" <Kuste...@discussions.microsoft.com> schrieb im
Newsbeitrag news:54F784C8-5A94-4788...@microsoft.com...
> Ich habe am SA die DEMO Version von XBase getestet. Das Problem ist, dass
> FOX
> einfach viel besser ist. Bei der DEMO, die ich getestet habe, muss man
> noch
> auf dem DOS Prompt arbeiten und einen eingenen Editor verwenden, eben wie
> Clipper früher.
>
> Also im jetzigen Entwicklungsstand ist XBase für mich zur Zeit keine
> Alternative.
>
> Asche auf mein Haupt für meinen Eintrag vom 16.3.07
>
> Ich bleibe vorerst bei FoxPro und in den nächsten 8 Jahren wird sich schon
> etwas ergeben. Ich bin sicher, dass irgend eine Firma sieht was in FoxPro
> steckt und kauft MS dieses Produkt wieder ab oder es gibt eine Opensource
> Version. Ich habe mich im Netz ein bisschen umgesehen und es gibt auch in
> Amerika eine sehr grosse Anhängerschaft von FoxPro.
>
> Wir schauen uns einfach alle um und machen noch ein bisschen Druck auf MS.
>
> Euer
> Peter
Michael Bickel
Alternativen, die wirklich vielversprechend erscheint.
Grüße
Michael
Heiko J. Rintelen wrote:
--
Jörg Schneider
Klingt interessant, aber auch irgendwie dubios. Von wo die Kommen sieht
man auch nicht (oder ich übersehs).
Michael Bickel
hmmm :)
was ich mich nur frage ist, warum MS Foxpro nicht weiterentwickeln
konnte wie die Leute von Visual Objects Ihr Produkt oder die
Leute von etecnologia.net
Ziemlich ignorant eine Anwendergruppe und Ihre Wünsche so komplett zu
ignorieren.
Viele Grüße
Michael
--
Thomas Wilting
Michael Bickel schrieb:
>
> was ich mich nur frage ist, warum MS Foxpro nicht weiterentwickeln
> konnte wie die Leute von Visual Objects Ihr Produkt oder die
> Leute von etecnologia.net
>
> Ziemlich ignorant eine Anwendergruppe und Ihre Wünsche so komplett zu
> ignorieren.
Ich glaube du verwechselst da was. Es gibt eine große Anzahl von
Anwendern von FoxPro aber eine geringe Anzahl von Käufern der Versionen
8 und 9.
Das hast man schon bei der Hilfe gesehen. Was war das für ein geschrei,
VFP nur noch in Englisch. Da muss etwas passieren. Dann hat sich die
dFPUG an die Übersetzung gemacht und was war als alles fertig war?
Keiner hat sie gekauft. Die Hilfe war ein dickes Minusgeschäft. Erst
wollte sie jeder haben aber keiner wollte dafür bezahlen.
Genau so ist es mit VFP. Jeder schreit weil es eine neue VFP Version
gibt aber keiner will es kaufen oder sucht nach Tricks um Geld zu sparen.
"Ja meine 9 jährige Tochter macht in der Schule VFP ich brauch eine VFP9
Schulversion, damit sie daheim üben kann. Ach ja die DBI Controls laufen
ja auch damit oder? Dann nehme ich die auch noch."
"Mir langt mein VFP 6 damit kann ich alles machen."
Viele von denen schreien jetzt rum, weil VFP eingestellt wird oder
schreien jetzt nach Fixes für VFP 6 damit die Anwendungen unter Vista
fehlerfrei laufen.
Microsoft interessiert nicht wer VFP mal vor 10 Jahren gekauft hat,
sondern wer es heute kauft. Leider haben da die meisten gesagt: "Ich bin
nicht bereit 400 € für ne aktuelle Version auszugeben." Jetzt kommt die
Quittung dafür. Microsoft hat nicht mehr oder zu wenig an VFP verdient
also wird es eingestellt so ist das.
Arbeitest du noch für nen Kunden wenn er dich nicht dafür bezahlt? Nein
also warum sollte Microsoft das tun?
So ich hoffe mal, dass das einige zum Nachdenken anregt.
Viele Grüße Thomas
Michael Bickel
also wieviele Versionen MS von Foxpro verkauft oder eben nicht
verkauft, weiss ich nicht - woher soll ich das wissen und dass die
Leute alles umsonst wollen, betrifft nicht nur MS
(und so schlecht geht es denen nicht) - mein Bedauern hält sich da in
Grenzen. Und das man nicht permanent jedes Update kauft ist auch normal.
Mein Quickbooks z.B:. V 2000, dann 2005, mittlerweil aktuell 2007 -
habe ich auch noch nicht gekauft. So ungewöhnlich ist das doch nun
wirklich nicht.
Was die dt. Übersetzung angeht, so habe ich für 9 eine gekauft (was
aber "nur" Programm und Reportsystem)
- hier gab es wohl auch Probleme mit der Unterstützung, zumindest hat
mich nie eine versprochene CD erreicht...
Ich schätze mal die Verbreitung und Verkaufszahlen von Visual Studio
halten sich auch in Grenzen, sonst würde MS keine kostenlosen Versionen
verteilen...
Aus reiner Nettigkeit machen die das bestimmt nicht...
Foxpro hätte populärer sein können, wenn MS sich mehr bemüht hätte,
haben die das? schaue Dir doch die MS Seiten an - ist ja fast eine
Lebensaufgabe Foxpro zu finden.
Ich glaube eher, hier war gar kein Erfolg so richtig gewollt.
Viele Grüße
Michael
--
Holger Vorberg
ich antworte noch mal, meine Antwort, die ich im Laufe des Tages geschrieben habe, ist irgendwie
nicht in der NG angekommen.
> Ich denke ich habe es schon richtig verstanden.
> Auf dem Client wird eine Kopie der Datenbank abgelegt.
> Werden Daten geändert, werden diese zunächst nur in der Kopie auf dem Client geändert. Erst beim
explizieten update wird die Datenbank geändert.
so wie es aussieht, hast du es nicht richtig verstanden.
Ich denke, du redest vom "DataSet", das nur eine strukturelle Abbildung der Datenbank ist. So ein
Dataset kannst du nach deinen Wünschen mit DataTables und TableAdptern füllen, womit das ganze dann
mit einem VFP DB Container, der nur Views beinhaltet, vergleichbar ist. Alle diese Dinge wie
DataSet, DataTable und TableAdapter sind Klassen und jeder diese Klasse hat ihre Aufgabe. Wenn du
eine DataTable zu einem Objekt instanziierst, dann kannst du eine bestimmte Methode aufrufen und du
bekommst das Ergebnis einer von dir hinterlegten SQL Abfrage als komplettes Objekt zur Verfügung
gestellt. Als quasi das gleiche, als würdest du in VFP einen View öffnen. Und ein VFP View updatet
sich auch nicht von allein. Das musst du auch selbst veranlassen.
In VS 2005 gibt es die sog. typisierten DataSets. Diese sind ganz exakt auf die einzelnen Tabellen
abgestimmt und eine extreme Arbeitserleichterung. Also mitnichten "Steinzeit". Das ist hypermodern!!
Holger Vorberg
auch hier muss ich noch mal antworten. Irgendwie dringen nicht alle meine Antworten bis zur NG durch.
> Label auf Picturebox, versucht Hintergrund transparent zu machen -
> klappt nicht.
> (man musste dem Label erst mitteilen, dass er auf einer Picturebox
> sitzt).
>
> Musste ich erst 2 Zeilen Code dafür einsetzen - sowas habe ich seit
> mindestens 10 Jahren nicht mehr gesehen, sowohl bei Delphi als auch
> Foxpro langt da ein Klick.
die Transparenz wird über die Hintergrundfarbe geregelt.
Geh mal im Eigenschaftenfenster auf "BackColor" und dann auf "Web" -> "Transparent".
Sollte also auch bei VS .NET per Mausklick gehen.
> Das Anpassen des Grid-Moduls (z.B. Spaltenbreite) finde ich altmodisch
> - nix visuell? oder habe ich das übersehen?
offenbar lässt sich die Spaltenbreite nicht interaktiv sondern nur im Eigenschaftenfenster bzw. per
Code manipulieren.
> Ich bin noch nicht weit genug für eine abschließende Entscheidung -
> aber vieles erscheint mir unnötig kompliziert und eher rückschrittlich.
Das ist eine typische VFP Entwickler Angewohnheit, solche Entscheidungen von ein paar GUI Controls
abhängig zu machen und woanders ständig das Haar in der Suppe zu suchen.
Es gibt noch ein paar Tausend Klassen im .NET Framework, vielleicht solltest du dir die mal ansehen.
Michael Bickel
> Hi,
>
> auch hier muss ich noch mal antworten. Irgendwie dringen nicht alle
> meine Antworten bis zur NG durch.
>
> > Label auf Picturebox, versucht Hintergrund transparent zu machen -
> > klappt nicht.
> > (man musste dem Label erst mitteilen, dass er auf einer Picturebox
> > sitzt).
> >
> > Musste ich erst 2 Zeilen Code dafür einsetzen - sowas habe ich seit
> > mindestens 10 Jahren nicht mehr gesehen, sowohl bei Delphi als auch
> > Foxpro langt da ein Klick.
>
> die Transparenz wird über die Hintergrundfarbe geregelt.
> Geh mal im Eigenschaftenfenster auf "BackColor" und dann auf "Web" ->
> "Transparent". Sollte also auch bei VS .NET per Mausklick gehen.
Nö, tut sich nix.
Me.Label1.BackColor = Color.Transparent
Me.Label1.Parent = Me.PictureBox1
hilft (wenn das Programm läuft)
>
>
> > Das Anpassen des Grid-Moduls (z.B. Spaltenbreite) finde ich
> > altmodisch - nix visuell? oder habe ich das übersehen?
>
> offenbar lässt sich die Spaltenbreite nicht interaktiv sondern nur im
> Eigenschaftenfenster bzw. per Code manipulieren.
>
>
> > Ich bin noch nicht weit genug für eine abschließende Entscheidung -
> > aber vieles erscheint mir unnötig kompliziert und eher
> > rückschrittlich.
>
> Das ist eine typische VFP Entwickler Angewohnheit, solche
> Entscheidungen von ein paar GUI Controls abhängig zu machen und
> woanders ständig das Haar in der Suppe zu suchen. Es gibt noch ein
> paar Tausend Klassen im .NET Framework, vielleicht solltest du dir
> die mal ansehen.
Mußte Du Dir ja nicht so zu Herzen nehmen, die Menschen und Ihre
Vorlieben sind halt unterschiedlich. Muß ja auch nicht jeder das
gleiche nehmen und Alternativen sind doch immer gut.
VB.NET und ich - das wird eher nix, aber einige Anwender haben ja
interessante "Erweiterungen" oder "Zusatzsprachen" heute erwähnt.
In Kombination damit könnte es für mich interessanter sein.
Unsere Anwendung und VB .NET - das wäre viel zu viel Aufwand. Das
"Transparent" - Problem würde einiges an Coding alleine verursachen,
vom Rest ganz zu schweigen. Aber wie gesagt, mit diesem .NET Compiler
oder ev. Vulkan .NET, wenn das wirklich was taugt, das wäre was.
Man ist ja auch nicht unter dem ganz großen Zeitdruck.
Viele Grüße
Michael
> Tschüß,
>
> Holger Vorberg
> MS Visual FoxPro MVP
> dFPUG Regionalleiter Bielefeld
--
karl twele
"Thomas Wilting" <tho...@prolib.de> schrieb im Newsbeitrag
news:OMD9DrIc...@TK2MSFTNGP06.phx.gbl...
Hallo Thomas,
> Ich glaube du verwechselst da was. Es gibt eine große Anzahl von Anwendern
> von FoxPro aber eine geringe Anzahl von Käufern der Versionen 8 und 9.
Mein Sohn hat eine Lehre als Fachinformatiker gemacht und wenn ich Ihn
frage, ob er was über VFP weiß, dann zuckt er mit den Achseln. MS versäumt
also bewust, dieses Produkt zu vermarkten. VFP kennt schlichtweg kaum einer.
Der Grund ist vermutlich, eine von langer Hand vorbereitete Bereinigung der
Produktpalette zu gunsten von VS. Hier entsprechen die Verkauifszahlen den
Marketinganstrengungen und betrachtet man den Preis, dann weiß man auch
warum MS so handelt.
> Das hast man schon bei der Hilfe gesehen. Was war das für ein geschrei,
> VFP nur noch in Englisch. Da muss etwas passieren. Dann hat sich die dFPUG
> an die Übersetzung gemacht und was war als alles fertig war? Keiner hat
> sie gekauft. Die Hilfe war ein dickes Minusgeschäft. Erst wollte sie jeder
> haben aber keiner wollte dafür bezahlen.
Ich kauf doch kein so lernintensives Produkt, ohne eine für mich
verständliche Dokumentation. Ich will ja kein Englisch damit lernen, sondern
Proigramme schreiben. Eine wichtiger Grund, warum ein Update für VFP 6.0
nicht von mir gekauft wurde. Nachdem es dann eine Doku in deutsch gab, ist
nicht einzusehen, daß ich das zusätzlich bezahlen soll, so eine
Vorgehensweise ist bei Produkten nicht üblich und erweckt nicht gerade das
Vertrauen für einen Kauf.
> "Mir langt mein VFP 6 damit kann ich alles machen."
Besser ist FP 2.6, das ist nämlich super gut dokumentiert. Hab ich mir dann
VFP 6.0 gekauft, dann heißt es in Bezug auf Dokumentation abstriche zu
machen und wochenlang zu konvertieren oder zu ändern. Ist auch sicher eine
gute Sache alles noch mal zu erneuern aber doch nicht in solch einer
Geschwindigkeit. So ist der nächste Sprung dann eben VFP 9.0, ein für
viele, vernünftiger Zeitraum für eine Erneuerung.
> Microsoft interessiert nicht wer VFP mal vor 10 Jahren gekauft hat,
> sondern wer es heute kauft. Leider haben da die meisten gesagt: "Ich bin
> nicht bereit 400 € für ne aktuelle Version auszugeben." Jetzt kommt die
> Quittung dafür. Microsoft hat nicht mehr oder zu wenig an VFP verdient
> also wird es eingestellt so ist das.
Ich bin mir ziemlich sicher, wenn die Väter von FP nicht an MS verkauft
hätten, würde es dem Produkt heute besser gehen und diejenigen, die das dann
weiterentwickelt hätten, würden wunderbar von Ihren verkauften Lizenzen
leben. Vielleicht würde sogar Dbase noch leben und es gebe eine gesunde
Konkurenz.
> Arbeitest du noch für nen Kunden wenn er dich nicht dafür bezahlt? Nein
> also warum sollte Microsoft das tun?
Wir bezahlen sehr gut an MS, z.B. über viele Jahre für den Kauf von
teilweise schlecht entwickelten Betriebssystemen und wenn ich den ganzen
Ärger mit diesen Produkten zusammenrechne, dann müsste MS noch zuzahlen.
> So ich hoffe mal, dass das einige zum Nachdenken anregt.
Nachdenken tun wir, aber wie wir es vermeiden können weiter einem
Monopolisten zu unterstützen, der ohne große Not seinen Kunden in den
Hintern tritt und eben mal erwartet, daß man jahrelange Arbeit über Bord
schmeißt und viele Monate Arbeit in eine Alternative investieren soll. Dabei
ist die Alternative unverschämt teuer, schlecht dokumentiert, sehr
kompliziert und für den einen oder anderen in Ihrer Struktur nicht mehr so
leicht zu überschauhen..
Eine Entwicklungsumgebung, die in die andere Richtung geht und die Dinge
einfacher und verständlicher macht, wäre sicher ein Verkaufsschlager.
Gruß KT
Michael Bickel
fehleranfällig (siehe BDE) oder z.T. unmöglich ist und mir auch in
.NET fehlt (abgesehen von Umwegen)
ist das direkte schreiben in ein Format wie z.B. dbf (und wo ich kein
Extra-Tool wie Access brauche) und entsprechende Unterstützung durch
eine geeignete Klassenbibilothek o.ä.
Für kleineres einfach unersetzlich. Hier würde ich mir von MS
wünschen, dass - gerade für Foxpro - Umsteiger - in der nächsten
Version einfach was dabei ist.
Sollte doch möglich sein.
Viele Grüße
Michael
Holger Vorberg wrote:
> > .... das sieht spannend aus und ist das erste von den ganzen
> > Alternativen, die wirklich vielversprechend erscheint.
>
> es erscheint zumindest interessant, obwohl die Sprache, den
> Screenshots nach zu beurteilen, relativ weit weg von VFP ist.
>
> Als Vorteil würde ich jedenfalls die Fähigkeit betrachten, direkt
> .DBF Dateien verwenden zu können.
>
> Sehr geschichtsträchtig ist aber auch der Name "Vulcan". So war doch
> der UrVorgänger von dBASE und FoxBase ein Produkt mit exakt diesem
> Namen. <g>
--
Christoph Dreßler
>In VS 2005 gibt es die sog. typisierten DataSets.
Wobei diese bei DB-Strukturänderungen praktisch unwartbar sind. In der
.NET-Gemeinde scheinen deshalb viele bei untypisierten zu beleiben.
mal abgesehen von den Code-Monstern die da entstehen...
Aber meine Frage: gibt es für .NET eine auf DB-Verarbeitung
zugeschnittenes Framework, das dem VFP-Umsteiger .NET schmackhafter
macht? Oder selber machen? Ich habe mir mal eine View-Klasse
geschrieben, in der Hoffnung, eventuelle Portierarbeiten zu
rationalisieren. Das ganze liegt mangels Zeit leider auf Eis, lies
sich aber vielversprechend an.
Grüße!
-christoph
Jürgen Wondzinski
>> gibt es für .NET eine auf DB-Verarbeitung zugeschnittenes Framework,
Klar doch. Drum verweise ich immer wieder auf www.Strataframe.net; die
stammen original aus der FoxPro Scene, wissen also, wie der Fux mit Daten
umgeht. Deren Framework ist wirklich sehr datenorientiert (gibt sogar ein
Browse <g>), inzwischen (dank unserer Mitarbeit) auch mehrsprachig
(englisch/deutsch/etc) und schon mehrfach auch im deutschen Raum im Einsatz.
StrataFame ist zwar bei ProLib im Vertrieb, aber da unser Webauftritt gerade
überarbeitet wird, ist leider unser Shop nicht unbedingt das, was man auch
nur annäherungsweise als "aktuell" bezeichnen könnte, und daher findest du
momentan auch noch keine Infos zu Strataframe bei uns. Aber wenn dann alles
wieder tut, dann... <g>
Daher bitte einfach telefonisch ordern bzw auf der Hersteller-Website
nachlesen.
--
Jürgen Wondzinski
Microsoft Visual FoxPro Technologieberater
Geschäftsführung ProLib Software GmbH
Microsoft Most Valuable Programmer seit 1996
Jürgen Wondzinski
in der nächsten Version ist "SQL-EveryWhere" enthalten, das entspricht schon
eher der FoxPro Denke: ne kleine Datenbank-Engine, die nur läuft, wenn du
sie brauchst, die mit in der Applikation enthalten ist (also keine
SQLExpress oder MSDE Installation mit Adminrechten notwendig) und die auch
im Flug Tabellen erstellen kann etc. Netterweise ist SqlEveryWhere
eigentlich die SQL-CE Engine, also ne extrem abgespeckte JET-Engine, die
später dann als SQL-Mobile auf PDAs und Tablet-PCs erschien, und nun sich
als SQL-EveryWhere in NET wiederfindet. Sie hat die üblichen Feldtypen, und
kann alle standardmässigen SQL-Befehle. Ist aber nix für Multiuserbetrieb
etc, sondern soll wirklich nur als lokales Zwischenlager etc gesehen
werden. Dei Frage, warum se nicht einfach die VFP-Engine integrieren,
konnte mir MS bislang nicht beantworten.... :(
Hans-Peter Grözinger
> Dei Frage, warum se nicht einfach die VFP-Engine integrieren,
> konnte mir MS bislang nicht beantworten.... :(
... wer bräuchte dann für kleine Anwendungen einen SQL-Server
bzw. die Express-Version?
Wenn man schon mal auf der Express ist, ist der Schritt nicht
mehr so groß ...
Das wird so gemacht wie bei den Studentenversionen die es umsonst
gibt. Kenn man das erstmal wechselt man eher zur besseren Kauf-
version als auf was anderes was es eventuell umsonst gibt.
Man müßte je vielleicht wieder was dazulernen.
--
Hans-Peter Grözinger
TOFU ist gedankenlose Resourcenverschwendung.
http://einklich.net/usenet/zitier.htm
http://support.microsoft.com/default.aspx?scid=fh;DE;NGNetikette
Heiko J. Rintelen
Mein erstes Entwicklungssystem für Windows war Windev. Das hat sehr viele
Ähnlichkeiten mit VFP, besonders die Datenbank-Engine (hiperfile..). Damals
hatte ich Version 4 und 5 im Einsatz, und obwohl ich die "englische" Version
gekauft habe, waren viele Kommandos und sogar Kontrollstrukturen noch in
französich..ein frenglisches Sprachgemisch, was erst mit Version 5 etwas
besser
wurde. Aber ansonsten war es ein sehr komfortables Entwicklungssystem, dem
Fux weit überlegen (enthält neben IDE noch Source Code Controllsystem,
Daten-
Model-Editor a la XCase, viele viele Wizards etc..)
Guckst Du : http://www.windev.com/index.html
Mittlerweile gibt es Version 10 und was mich damals abgeschreckt hat
hinsichtlich
"frenglisch" sollte erledigt sein. Man kann jetzt sogar eine Expressversion
zum
testen runterladen. Aber vorsicht : Im Gegensatz zum Fux ist es recht teuer,
und
zumindest damals lief es nur über einen Dongle, d.h. man sollte je
Arbeitsplatz auch
einen Lizenz erwerben (was natürlich auch jeder Fux-User gemacht hat...:-).
Das mit
dem Dongle ist für mich nicht so schlimm, da ich entwicklungstechnischer
Einzel-
kämpfer bin...
Gruß
Heiko
"Michael Bickel" <Michael...@esmb.de> schrieb im Newsbeitrag
news:OOG6WeRc...@TK2MSFTNGP04.phx.gbl...
Christoph Dreßler
ja, super, danke! Gibt es eine deutsche Plattform (Forum) dafür?
Ich werde mir das auf jeden Fall ansehen. Über OleDB läuft ja auch der
Fux. Schon getestet.
Für Dich muss das ja eine harte Zeit sein, so als alter Fux-Hase.
Obwohl - bis zu Rente läuft er ja noch locker... Wobei für Prolib
konkrete Migrationspfade VFP->Framework->.NET sicher ein interessantes
Thema sind. Ich würde da direkt mal Bayern besuchen ;-)
-christoph
Jürgen Wondzinski
StrataFrame hat sogar extra Datenzugriffsklassen speziell für VFP, um eben
die Schankerl der VFP-Datenbank zusätzlich nutzen zu können.
> Für Dich muss das ja eine harte Zeit sein, so als alter Fux-Hase.
Nicht für nur für mich; wir haben ja inszwischen 42 Leuts in 5 Standorten,
von denen 2/3 in VFP unterwegs sind. Die Ausbildung, Training und Migration
allein der Programmierer und Arbeitsplätze kostet pro Nase ca 20.000 Euro;
und die daraus resultierenden 800 KiloEuro musst du erst mal vorab
erwirtschaften.
DAS sind Sachen, die Microsoft absolut nicht begreift; sich hinzustellen und
zu sagen, anstelle von VFP kann man doch "einfach" mit NET (oder was immer)
weitermachen, ist schnell gesagt, aber für viele nur schwer zu machen. Denn
es ist ja nicht einfach mit "ich kauf mir ein NET Packerl" getan, der
grösste Kostenblock entsteht durch den Arbeits- und Verdienstausfall während
der Lernphase. Und wer kann schon mal eben für 3 Monate seine Kunden
abschalten, damit er in Ruhe und konsequent sich auf ein neues System
einarbeitet?
> Obwohl - bis zu Rente läuft er ja noch locker...
Soso, scheinbar hab ich schon ein Tattergreis Image? ;)
> Wobei für Prolib konkrete Migrationspfade VFP->Framework->.NET
> sicher ein interessantes Thema sind.
Öhem... ProLib ist schon seit einem Jahr tragender Teil des
www.VFPConversion.de Projektes in Zusammenarbeit mit Markus Egger's
www.VFPConversion.com von EPS (Markus war früher mal Mitarbeiter der ProLib,
hat sich dann in den USA selbständig gemacht, war noch einige Jahre VFP-MVP
und hat sich dann schon sehr früh auf NET spezialisiert)
> Ich würde da direkt mal Bayern besuchen ;-)
Nicht unbedingt notwendig. Wir kommen zu euch... Aus der engen
Zusammenarbeit mit EPS resultiert auch unter anderem wieder eine neue
VFPConversion Workshop-Tour im Juni. Voraussichtlich Hamburg, Berlin,
Düsseldorf, Stuttgart, München. Genaueres in ca zwei Wochen.
Aber trotzdem noch mal in aller Deutlichkeit: Es gibt zur Zeit keinerlei
Notwendigkeit, in Hektik zu verfallen. Für VFP-Entwickler ist selbst die
aktuelle NET Version immer noch in einigen Bereichen ein Rückschritt,
VB-Entwickler haben im Gegenzug schon viele Öha-Effekte, weil sie so langsam
ne Ahnung bekommen, was Objekt-Orientierung und direkte SQL-Einbindung (wie
sie in VFP schon seit über 10 Jahren existierten) tatsächlich an Nutzen
bringen.
Daher: Abwarten, auf die nächste NET Version mit hoffentlich dann wirklich
brauchbarer SQL-Integration hoffen und sich nicht kirre machen (lassen).
Michael Bickel
> Daher: Abwarten, auf die nächste NET Version mit hoffentlich dann
> wirklich brauchbarer SQL-Integration hoffen und sich nicht kirre
> machen (lassen).
Ein Problem dabei ist: umso mehr man an einer aktuellen Version nun
erweitert, umso mehr muss man später konvertieren.
Hauptproblem ist nur, dass es ohne weiteres keinen echten Ersatz gibt,
zumindest nicht für jedes Programm.
Und wenn man lange an einem Programm gearbeitet hat, bringt es dann zu
einem Punkt, wo man anfängt zufrieden zu sein und dann erklärt einem
MS: ach, wir haben was besseres,
mach doch bitte noch mal alles neu mit Dingsda.... da ist man echt
begeistert.
Die Spanier habe da ja eine Kampagne gestartet....
http://www.masfoxpro.com/
Man könnte ja mal Optimist sein und hoffen, dass es MS sich dann doch
nicht so einfach macht.... und sich wenigstens etwas beeindruckt zeigt.
Es würde ja zunächst reichen, wenn MS garantiert, dass Foxpro auch zu
zukünftigen Betriebssystemen kompatibel gehalten wird.
32bit wird es ja noch länger geben... nicht nur Foxpro.
Viele Grüße
Michael
Michael Drechsel
wrote:
>
> Guckst Du :http://www.windev.com/index.html
>
Hallo,
hab mir die Expressversion mal spassenshalber gegönnt. Ist ganz
witzig, bisschen zu bunte IDE für meinen Geschamck, lässt aber
offenbar bei der grafischen Gestaltung der Programmoberfläche keine
Wünsche offen. Die Frage ist nur: Macht da jemand proffesionell was
mitt ? In Frankreich und der franz. Schweiz scheint es wohl ganz gut
verbreitet zu sein, ein paar diesbezügliche Stellenazeigen hab ich
auch gefunden, aber in Germany Fehlanzeige.
Für meine Begriffe sollte eine moderne Programmiersprache so viel wie
möglich grafisch lösen können, ohne den Code dahinter natürlich nicht
zu vergessen.
Gruss MD
Jochen Kirstaetter
=?Utf-8?B?RGlldGVyIFRhdXR6?= <Diete...@discussions.microsoft.com>
wrote in microsoft.public.de.fox:
> Mal eine bescheidene Frage. Ich habe mich auch mal so vorsichtig mit
> C# beschäftigt. Was mir aber vollkommen unklar ist - was mache ich
> mit meinen vielen Berichten ? Welche Alternative gibt es da ?
Hm, da wird dir wohl kaum was anderes übrig bleiben, als zu konvertieren.
Entweder Crystal Reports oder Microsoft Reporting Services.
Als Übergangslösung kannst du dir einen VFP COM-Server (EXE) schreiben,
welcher weiterhin die Reports ausgibt.
--
Kind regards, JoKi
Jochen Kirstätter
-------------------------------------------------------------
ProLib Ltd.
Module 02A5, Level 2 - Cyber Tower - Cybercity, Ebene Reduit
Tel: +230 466 0030 Fax: +230 467 9892
Mail: jo...@prolib.mu Web: http://www.prolib.mu/
Jochen Kirstaetter
=?Utf-8?B?SG9sZ2VyIFZvcmJlcmc=?= <ei...@die-vorbergs.de> wrote in
microsoft.public.de.fox:
>> Mir ist es sowieso egal, hauptsache nicht Microsoft.
>
> aha, und du findest, dass du mit so einer Einstellung in einer
> Microsoft Newsgroup richtig platziert bist. <bg>
Und das kommt von dir, der in dieser VFP NG ebenfalls richtig platziert
ist, hm? Lieber erstmal an die eigene Nase fassen...
Jochen Kirstaetter
Boas Enkler <in...@it-design.biz> wrote in microsoft.public.de.fox:
> das hauptproblem ist unamaged Code.
> Also wenn du z.bsp. einen manuellen API Call machst, kann mono den
> natürlcih nicht wrappen und wenn die Anwendung uaf Linux läuft krachts.
> Deswegen wird u.a. empfohlen praktisch nur ,wenn möglich, mit managed
> code zu arbeiten.
Hast du schon auf Mono programmiert bzw. gearbeitet?
Neee, sonst würdest sowas nicht schreiben.
Jochen Kirstaetter
=?Utf-8?B?SG9sZ2VyIFZvcmJlcmc=?= <ei...@die-vorbergs.de> wrote in
microsoft.public.de.fox:
> dir scheint wohl das Klima an deinem neuen Arbeitsort nicht so richtig
> zu bekommen. <g>
Easy... Klima hier ist super. Und morgen geht's wieder zum Tauchen.
> Lies doch mal deine eigenen NewsbeitrƤge. Du stƤnkerst nur rum. Ich
> vermisse irgendwie dein Fachwissen in deinen BeitrƤgen.
'nur' - interessant. Naja, subjektive Wahrnehmung.
Ansonsten beantworte ich selbstredend auch andere Threads und gebe
Hilfestellung.
> Und wenn hier etwas fehl am Platze sein sollte, dann mĆ¼sste es
> eigentlich deiner Auffassung nach der gesamte Thread mit dem Titel
> "Alternative zu FoxPro...." sein.
Nö, das sicherlich nicht.
Der Thread ist hier genau richtig, da es ja um FoxPro im entferntesten
geht. Nur die Diskussion ist halt ein wenig emotionaler als Fachsimpelei.
Ich find's okay, das ist nicht das Thema, nur auf Dauer... naja, ich weiß
nicht so recht.
War schon interessant zu sehen, dass es doch etwa 3 Tage gedauert hat bis
auf das Announcement von Microsoft überhaupt 'ne Reaktion kam.
Und ich bin mal gespannt, wie viele 'Alternativen' im Laufe der Zeit noch
hier in der FoxPro-NG vorgestellt werden. Wozu 'ne Alternative? Das Thema
ist eh erst in etwa 3 bis 5 Jahren richtig diskutabel. Aktuell gibt's de
facto keine Alternativen - wozu also diskutieren?
Jochen Kirstaetter
=?Utf-8?B?SG9sZ2VyIFZvcmJlcmc=?= <ei...@die-vorbergs.de> wrote in
microsoft.public.de.fox:
> es stellt sich die Frage, wie man nun "Alternative" definiert. Das tut
> vermutlich jeder für sich auf andere Weise.
Exakt.
> Wer für sich sagt, eine Alternative zu VFP ist nur dann etwas, was
> genau wie VFP ist, dem muss man sicherlich sagen, diese Alternative
> gibt es nicht.
Ebenfalls korrekt:
Ein Porsche ist keine Alternative zu einem Ferrari und umgekehrt.
> Für mich ist eine Alternative einfach nur eine "weitere
> Möglichkeit". Und da steht für mich VS.NET an erster Stelle in der
> Liste. Das hab ich schon seit Monaten so gesehen und aufgrund der
> aktuellen Ereignisse (persönlicher Natur) muss ich mir selbst Recht
> geben. Wie andere das für sich sehen ist mir im Grunde egal. Ich kann
> nur von meinen Erfahrungen berichten und wenn jemand meint davon zu
> profitieren oder sich davon abschrecken zu lassen, bitte sehr! <g>
Joah, daher nutze ich mein Wissen, dass ich aus der Zeit VOR VFP (Perl,
PHP, MySQL und und und) erworben habe und kombiniere seit Jahren mein
Wissen ÜBER VFP in anderen Programmiersprachen. Und umgekehrt, denn im .NET
Framework sind auch nette Lösungen und Konzepte zu finden, die ich gerne in
VFP hätte und dann wird's implementiert.
> Ich bin auch der Meinung, dass im Augenblick nicht unbedingt der Druck
> zum Umsteigen so groß ist.
Exakt.
Und wie wir alle wissen, wird nichts so heiß gegessen wie es gekocht.
Und aktuell nach Alternativen zu suchen, um einen Umstieg zu machen, naja,
andere Baustelle. Aktuell sollte man bei VFP bleiben, und sich über die
nächsten Monate ruhig und gewissenhaft mit anderen Technologien und
Lösungen beschäftigen und sich dann entscheiden.
Ja, .NET kann ziemlich Spass machen, aber auch extremst viel Nerven kosten.
Und mal ganz bescheiden formuliert, etliche Klassen im Framework sind auch
nur Adapter für die Windows API.
Bis denne, JoKi
Jürgen Wondzinski
>> Du stänkerst nur rum. Ich vermisse irgendwie dein Fachwissen in deinen
>> Beiträgen.
Hallooo? Ja gehts noch? Was ham'se denn dir heut ins Wasser getan?
Das selbe könnte ich bei einigen deiner Messages dir auch vorwerfen.
Etwas mehr Professionalität könnt hier alle Beteiligten nicht schaden, auch
oder gerade weil dieses Thema leicht hochkochen kann.
Heiko J. Rintelen
In Frankreich ist Windev natürlich am weitesten verbreitet.
Aber auch in USA gibt es Leute, die es nutzen. In Deutschland
gibt es einen Vertriebspartner, ich weiß nicht wie gut sonst der
Support ist. Auch gibt es Foren und eine Comunity-Homepage..
Ich finde daß man doch sehr viel rein grafisch erledigen kann..
Wo soll es da mangeln? Die zugrundeliegende Sprache ist auch
recht komplett..und wenn sie wirklich in richtigem Englisch funktioniert
ist es sicher eine gute Sache...
Gruß
Heiko
"Michael Drechsel" <nos...@spig.com> schrieb im Newsbeitrag
news:1175169415.5...@d57g2000hsg.googlegroups.com...
Michael Drechsel
wrote:
Die zugrundeliegende Sprache ist auch
> recht komplett..und wenn sie wirklich in richtigem Englisch funktioniert
> ist es sicher eine gute Sache...
Hallo,
bin mal bisschen tiefer eingestiegen und muss sagen, ich bin wirklich
beeindruckt.
Es erschlägt eine förmlich von den Features, die da eingebaut sind.
Frage mich, wo da der Haken ist. Es ist eigentlich genau das, was ich
mir wünschen würde ...
Hat sogar ne eingebaute Datenbank, was sie allerdings taugt ....
Wo hat man das schon,
... im Reporting Tool eingebauter Export to HTML, native PDF (ohne
DruckerTreiber), Word, Excel, XML
... Grid mit eingebauter Suche, Sortierung, Summe, Durchschnitt
... automatische Tests
... eingebaute Setup-Tools incl. Patchfähigkeit
.... eingebaute Programmdokumentation
... native exe-Erstellung
... viele Controls, incl. Barcode, Scanner etc.
Naja, 30 Millionen Franzosen können sich nicht irren ... :-)
Heiko J. Rintelen
Einen großen Haken gibt es da eigentlich nicht. Mich hat
damals nur genervt, daß manche Kontrollstrukturen, obwohl im
englischen Handbuch als "FOR ..NEXT" etc. beschrieben dann
doch auf französich formuliert werden mussten. Das war wohl
ein Problem dieser Version 4 und 5, wobei Version 5 schon
ziemlich problemlos war. Die eingebaute Datenbank halte ich
für recht gut und schnell, aber man kann ja auch XBase-DB
direkt nutzen sowie SQL-Server..
Was ich bei der aktuellen Version 10 nicht sagen kann ist, ob
wirklich reine DOTNET-Anwendungen als managed code erstellt
werden können. Falls nicht wäre es keine echte Alternative zu VFP..
Bist Du da schon so weit eingestiegen um das beurteilen zu können?
Was sicherlich ganz beruhigend ist, ist die Tatsache, daß der Entwickler
PC-Soft ausschließlich Windev und Webdev als Produkt entwickelt, d.h.
solange diese Firma existiert wird es auch Weiterentwicklung geben, die
können das Produkt nicht so schnell kippen wie das MS mal eben mit
VFP machen kann..
Gruß
Heiko
"Michael Drechsel" <nos...@spig.com> schrieb im Newsbeitrag
news:1175284090.8...@b75g2000hsg.googlegroups.com...