Very Computer

>I currently have a FoxPro 2.5 (i think) application, its
>for Dos anyway, very much a legacy application, which
>runs most of the day to day operations for the business,
>however its begining to show its age (about 14 years
>I think) and is getting a bit unreliable, to me it looks like
>it's an old rust bucket of a car, bits falling off here and there,
>fortunately the doors are still there and the engine still
>kicks over :)

>Anyway, its desparetly overdue for re-writing in preferably
>a Graphical User Interface, the obvious choice Win98/NT.
>I haven't the original source code so it'll be a bit of a learning
>curve, though I have managed to print out the structures of
>the database files so I know roughly how its constructed.

>Its main jobs are invoicing, inventory, job costing and other
>accounting issues. Nothing terribly complex or difficult.

>The problem I'm having is I just don't know what database
>to commit myself to writing this in. I currently have Visual
>dBase 7.0 pro, but I haven't any experience in dBase and
>there are no 3rd part support books for it yet! Although they
>are apparently in the writing, I don't know if I can wait that
>long.

>I also have just recently bought Teach Yourself COBOL in
>24 hours, which includes the Fujitsu COBOL v3 starter kit,
>which is a freebie complier/editor, and not all that bad either
>I might add. I think if I commit myself I should be able to write
>it in COBOL, and from what I've read, COBOL still has a future
>going for it. However I don't want to start a war or anything on
>whether COBOL is dead or alive or has a future, just if anyone
>would recommend trying to learn and write in it.

>COBOL seems to default to a Text/Console interface, which I
>must admit that I still do for some reason actually prefer a text
>interface, but everyone now wants GUI's and point 'n' click so I
>guess there isn't too much choice there, PowerCOBOL is also
>included which is a GUI for COBOL, though I don't know how
>good it is.

>The other choice would seem to be MS Visual FoxPro, which I
>also know very little about. Would FoxPro be able to import the
>existing databases? Its not terribly important, seeing as the data
>is purged at the end of financial year anyway, just the Product info
>and Stock would have to be re-entered, which isn't too much of a
>task. But it would be great if it could.

>Anyway, is Visual FoxPro easy to learn? Good support, and
>worth my time learning?

>Any advice/ideas on this would be much appreciated,
>Thanks in Advance,
>Chris Lee

>I also wrote a similar application in FoxPro 2.5 for DOS and needed to
>modernize it, so I tried Visual Foxpro. I gave it up rather soon. FoxPro in
>itself is some kind of attempt to turn the old xBase flat file database
>format into some kind of relational database, and they stretch it further
in
>Visual FoxPro, apparently to accomodate those who want to upgrade their old
>xBase applications into something reasonably modern. But I must say I think
>the whole FoxPro model is obsolete. There is too much of the old clunky
>xBase in it.

>If you have the time, learn Access or Visual Basic and rewrite the
>application in one of them (Access uses VB language so it is about the
same,
>but Access has more high level development features which makes it possible
>to do most things without writing code at all. Later versions of VB also
has
>wizards to do most coding for you, and I personally think that VB 5 or 6
are
>real good choices for database development. It is simple to use, gives you
>access to all standard Windows GUI features and now also compiles
reasonably
>well.

>There is somewhat of a learning curve involved for an old xBase developer,
>but once you get a hold of object oriented programming and SQL then you
will
>find a new world opening up. Get a good book on OOP and SQL.

>If you just want to turn your old DOS application into Windows as fast as
>possible without getting involved with development work, then get Visual
>FoxPro and hope that it manages to upgrade your 2.5 code properly. For me
it
>didn't.

>Per

>>Hi,

>>I currently have a FoxPro 2.5 (i think) application, its
>>for Dos anyway, very much a legacy application, which
>>runs most of the day to day operations for the business,
>>however its begining to show its age (about 14 years
>>I think) and is getting a bit unreliable, to me it looks like
>>it's an old rust bucket of a car, bits falling off here and there,
>>fortunately the doors are still there and the engine still
>>kicks over :)

>>Anyway, its desparetly overdue for re-writing in preferably
>>a Graphical User Interface, the obvious choice Win98/NT.
>>I haven't the original source code so it'll be a bit of a learning
>>curve, though I have managed to print out the structures of
>>the database files so I know roughly how its constructed.

>>Its main jobs are invoicing, inventory, job costing and other
>>accounting issues. Nothing terribly complex or difficult.

>>The problem I'm having is I just don't know what database
>>to commit myself to writing this in. I currently have Visual
>>dBase 7.0 pro, but I haven't any experience in dBase and
>>there are no 3rd part support books for it yet! Although they
>>are apparently in the writing, I don't know if I can wait that
>>long.

>>I also have just recently bought Teach Yourself COBOL in
>>24 hours, which includes the Fujitsu COBOL v3 starter kit,
>>which is a freebie complier/editor, and not all that bad either
>>I might add. I think if I commit myself I should be able to write
>>it in COBOL, and from what I've read, COBOL still has a future
>>going for it. However I don't want to start a war or anything on
>>whether COBOL is dead or alive or has a future, just if anyone
>>would recommend trying to learn and write in it.

>>COBOL seems to default to a Text/Console interface, which I
>>must admit that I still do for some reason actually prefer a text
>>interface, but everyone now wants GUI's and point 'n' click so I
>>guess there isn't too much choice there, PowerCOBOL is also
>>included which is a GUI for COBOL, though I don't know how
>>good it is.

>>The other choice would seem to be MS Visual FoxPro, which I
>>also know very little about. Would FoxPro be able to import the
>>existing databases? Its not terribly important, seeing as the data
>>is purged at the end of financial year anyway, just the Product info
>>and Stock would have to be re-entered, which isn't too much of a
>>task. But it would be great if it could.

>>Anyway, is Visual FoxPro easy to learn? Good support, and
>>worth my time learning?

>>Any advice/ideas on this would be much appreciated,
>>Thanks in Advance,
>>Chris Lee

>I also wrote a similar application in FoxPro 2.5 for DOS and needed to
>modernize it, so I tried Visual Foxpro. I gave it up rather soon. FoxPro in
>itself is some kind of attempt to turn the old xBase flat file database
>format into some kind of relational database, and they stretch it further
in
>Visual FoxPro, apparently to accomodate those who want to upgrade their old
>xBase applications into something reasonably modern. But I must say I think
>the whole FoxPro model is obsolete. There is too much of the old clunky
>xBase in it.

>If you have the time, learn Access or Visual Basic and rewrite the
>application in one of them (Access uses VB language so it is about the
same,
>but Access has more high level development features which makes it possible
>to do most things without writing code at all. Later versions of VB also
has
>wizards to do most coding for you, and I personally think that VB 5 or 6
are
>real good choices for database development. It is simple to use, gives you
>access to all standard Windows GUI features and now also compiles
reasonably
>well.

>There is somewhat of a learning curve involved for an old xBase developer,
>but once you get a hold of object oriented programming and SQL then you
will
>find a new world opening up. Get a good book on OOP and SQL.

>If you just want to turn your old DOS application into Windows as fast as
>possible without getting involved with development work, then get Visual
>FoxPro and hope that it manages to upgrade your 2.5 code properly. For me
it
>didn't.

>Per

>>Hi,

>>I currently have a FoxPro 2.5 (i think) application, its
>>for Dos anyway, very much a legacy application, which
>>runs most of the day to day operations for the business,
>>however its begining to show its age (about 14 years
>>I think) and is getting a bit unreliable, to me it looks like
>>it's an old rust bucket of a car, bits falling off here and there,
>>fortunately the doors are still there and the engine still
>>kicks over :)

>>Anyway, its desparetly overdue for re-writing in preferably
>>a Graphical User Interface, the obvious choice Win98/NT.
>>I haven't the original source code so it'll be a bit of a learning
>>curve, though I have managed to print out the structures of
>>the database files so I know roughly how its constructed.

>>Its main jobs are invoicing, inventory, job costing and other
>>accounting issues. Nothing terribly complex or difficult.

>>The problem I'm having is I just don't know what database
>>to commit myself to writing this in. I currently have Visual
>>dBase 7.0 pro, but I haven't any experience in dBase and
>>there are no 3rd part support books for it yet! Although they
>>are apparently in the writing, I don't know if I can wait that
>>long.

>>I also have just recently bought Teach Yourself COBOL in
>>24 hours, which includes the Fujitsu COBOL v3 starter kit,
>>which is a freebie complier/editor, and not all that bad either
>>I might add. I think if I commit myself I should be able to write
>>it in COBOL, and from what I've read, COBOL still has a future
>>going for it. However I don't want to start a war or anything on
>>whether COBOL is dead or alive or has a future, just if anyone
>>would recommend trying to learn and write in it.

>>COBOL seems to default to a Text/Console interface, which I
>>must admit that I still do for some reason actually prefer a text
>>interface, but everyone now wants GUI's and point 'n' click so I
>>guess there isn't too much choice there, PowerCOBOL is also
>>included which is a GUI for COBOL, though I don't know how
>>good it is.

>>The other choice would seem to be MS Visual FoxPro, which I
>>also know very little about. Would FoxPro be able to import the
>>existing databases? Its not terribly important, seeing as the data
>>is purged at the end of financial year anyway, just the Product info
>>and Stock would have to be re-entered, which isn't too much of a
>>task. But it would be great if it could.

>>Anyway, is Visual FoxPro easy to learn? Good support, and
>>worth my time learning?

>>Any advice/ideas on this would be much appreciated,
>>Thanks in Advance,
>>Chris Lee

>There is some decompilers for FOXPRO 2.5 (I believe)
>So you get one , decompile the .app, .scx, .fxp or whatever you have.

>You have a nice bunch of original source-code files.
>Then with visual foxpro, make a project recompile, and PRESTO!
>Your app is runnig in windows, like magic. In short time, no rewriting
>That is in theory.

>Yes the language is easy to learn

>CONS: FOXPRO seems to be fading away. You will spend time and money in
>something that maybe will disassappear in a few years.
>Anyways, maybe it will worth. Because for data manipulation it i the best
>thing in the world.

>>CONS: FOXPRO seems to be fading away. You will spend time and money in
>>something that maybe will disassappear in a few years.
>>Anyways, maybe it will worth. Because for data manipulation it i the best
>>thing in the world.