none
FoxPro v9 vs Visual dBASE Plus 2.01 BDE 5.2.02

    Question

  • Hi there. I just installed a Visual FoxPro 9.0 and started "playing" with it. Tried to create a table - it is straightforward and then a form. It seems to be a rich platform.

    Something puzzles me though. I do have extensive experience with Visual dBASE PLUS and previous versions in terms of OO language and form/table designer. Thus I am trying to compare. I am attempting to migrate to MS software/platforms wholesale since the dBASE is offering limited options as compared to MS's tools. I am doing C# and Visual FoxPro at the same time.

    Anyway, So far, after about two hours of playing with FoxPro Form designer I encountered some problems. They might be due to my unfamiliarity with the setup. Perhaps there are some keys or designer options I have to switch or whatever to make it work the way I think it should.

    My major problem now: I cannot seem to find the source code that describes the form. There should be a set of constructors for all controls, the form itself, all the classes, etc. When I add methods there should be some functions in the file. In the designer there are tabs: CODE but when I click on them empty windows with white fields come up and that's it.

    Another thing I cannot comprehend is how containers work in here. In dBASE when you dropped a container on a form, the form becomes a parent of this container. You can drop controls (buttons, textboxes (they call them entryfields over there) on the container and the container object becomes a parent for those child control objects, etc. It is very easy to reference the whole hierarchy of objects this way. I could not accomplish it in FoxPro so far.

    in dBASE Plus we edit the source code extensively adding new functions after initial work with the designer. Where is the source code in here?

    Thanks.
    Thursday, September 15, 2005 7:46 PM

Answers

  • The source code is in the events, or methods you create for the form.  Each control, label, line, box or whatever has a complete set of OOP options and events where you can type in any code you wish to work on the object or the other objects.

    In the old version of foxpro you could edit the screen file, not anymore.

    We have containers with hierarchy of objects also.  You refer to them with something similar to this:
    Thisform.thiscontrol.thiscontrol.attribute

    For example:
    Thisform.txtLastName.Value = "Higgins"
    will change the value of this textbox to "Higgins"

    Another example:  A label on the form says "Name:"
    thisform.lblLastName.caption = "Last Name:"
    will change the LABEL called lblLastName to "Last Name"
    Thursday, September 15, 2005 8:12 PM
  • Furthermore, you can write custom methods to make things happen in tables or on the form.  We  use custom properties and methods to create custom procedures that can do anything you can dream up.

    Another example would be calculating tax from 2 fields called txtPrice and txtQuantity.  I would create a textbox called txtTaxAmount with a control source of a property called TaxAmount.  Create a property in the form called TaxAmount, another property called TotalCharge, and a custom method called CalcTax.  In the valid event in the txtPrice textbox I call a custom method called CalcTax like this:

    thisform.CalcTax()
    thisform.refresh()



    In the CalcTax method I would write:
    local nTotal, nTaxPercent, nTotalCharge

    *** select setup table to find tax percent stored in table
    select setup
    nTaxPercent = taxpercent

    *** calculate total price and tax
    nTotal = thisform.txtPrice * thisform.txtQuantity
    thisform.TaxAmount = nTotal * nTaxPercent
    thisform.TotalCharge = nTotal + thisform.TaxAmount

    Thursday, September 15, 2005 8:24 PM
  • Besides reading the Help file (CHM) which is not bad, you can follow the examples on the Task Pane (one of the toolbar buttons on the extreme right) or you can open it from the Command Box with:

    DO (_taskpane)

    This is an app written in FoxPro itself that gives you functionality, and discoverability of item and examples. It consustes of several sub-apps (panes) on the top toolbar. The one you should look at is Solution Samples. It consists of a TreeView Control with lots and lots of working examples with source code.

    Have fun!


    Also look at the richness of information in the VFP Wiki (also a web app fully written in VFP)
    http://fox.wikis.com/wc.dll?Wiki~ListCategories

    Thursday, September 15, 2005 10:38 PM
  • Wiki is "fast" in Hawaian. It is a concept started many years ago by Ward Cunningham. There are countless Wikis on many subjects. They are mainly a repository of information with collaboration from the community.

    Ours is at:
    http://fox.wikis.com/wc.dll?Wiki~FoxProWiki


    The most famous one is Wikipedia:
    http://en.wikipedia.org/wiki/Main_Page


    Visual FoxPro is not a part of .NET in that it does not compile to the CLR. But it can coexist and share information fairly easily through COM Interop

    Sample whitepaper:
    http://www.west-wind.com/presentations/VFPDOTNETiNTEROP/VFPDOTNETINTEROP.HTM

    VFP will work better with .NET in the next release, codenamed "Sedna". See the Sedna Roadmap at:
    http://msdn.microsoft.com/vfoxpro/roadmap
    Friday, September 16, 2005 11:05 AM
  • First of all welcome:)
    You can create forms and other objects using designers or via manual coding. I want to clarify a thing:
    You drop a container and drop controls on it in dBase like in .Net I guess. If so, procedure is a litlle different in VFP. First you rightclick and select edit (or Ctrl+click). Then add other controls. Otherwise other controls you drop are not part of the container.
    I don't know dBase (since dBaseIII+ at least) but a nice feature that I couldn't find in .Net. You can:
    -Create a dummy temp form,
    -drop some controls, arrange and add code to them
    -From menu select 'File\Save As Class' && selected controls create a container class
    Something like .Net's control class library but more flexible than that (maybe in future .Net versions:). Same is available for a single control and/or for compound container type controls like grid,pageframe etc.
    Friday, September 16, 2005 4:30 PM
  • Terminology is same. Event handler or event code. VFP is not very much different from .Net in that regard. For a control you have many delegates but might use only one - say click - in code.
    If you think of old days, source code was simple ASCII file. Any editing would be spoiled by designer. In VFP however designer generated code is in tables (scx for form, vcx for class and so on). You can 'hack' the scx, vcx and designer loads with your hacks (cool for me - I always liked manual touch rather than using mouse everywhere:) Also I can give you a tip to interact with your design surface during design time manually.
    Suppose you created a checkbox on form, set its font, color etc. Its caption would be something like "Room 1". You want 20 more of these checkboxes lined with 'same left' and only name and caption changes sequentially.
    -Drop a checkbox on form
    -It's selected by default if not Click to select
    -Go to command window and type
    Modify Command[ENTER] && or MC[space][ENTER] - case insensitive
    -Directly code your "builder" there. ie:

    ASelObj(aObj) && Creates an array of selected objects
    ASelObj(aObjFrm,1) && Creates an array which points to the parent container
    loChkRoom = aObj[1]
    loParent = aObjFrm[1]
    loChkRoom.Name='chkRoom1'
    loChkRoom.Caption='Room 1'
    For ix=2 to 20
      loChkRoom.CloneObject('chkRoom'+Ltrim(Str(m.ix)))
      With Evaluate('loParent.'+'chkRoom'+Ltrim(Str(m.ix))) && obj ref of clone
       .Caption = "Room "+Ltrim(Str(m.ix))
       .Left = loChkRoom.Left
       .Top = loChkRoom.Top + ( loChkRoom.Height + 2 ) * (m.ix - 1)
       .Autosize = .t.
      EndWith
    EndFor
    loParent.Refresh

    -[Ctrl+A] to select all code and rightclick "Execute Selection"
    (It executes selected code but doesn't save anywhere unless you say so - sort of same as select/copy a piece of code from anywhere and execute "ExecScript(_cliptext)" in command window)

    This sample doesn't show its power but  know that basically it's the same approach "builders" use. With this I rarely need to hack scx myself. For example, in designer properties like class/classlibrary are readonly. You can change them in code hacking scx or this builder approach too works:) - Disclaimer: Hacking forms/classes should always done with a backup and at one's own risk. If you do don't forget to compile.

    A final note (I was confused with it when I first stepped into VFP3 OOP from 2.x):
    There are methods and events. They're practically the same thing - "procedure" or function. Events are implicitly invoked (while you could explicitly invoke too) as a response to something, methods need explicit calls. (events are C# delegates which you subscribe by default). IOW in C# it looks like:

    private void myButton_click(object sender, EventArguments e) {}

    If you dblclick an object you get its events/methods code window (dropdown at top right shows the event, left shows the object - so left "myButton", right "Click")

    If you code something it's executed at runtime followed by deafult base code of event. A typical example of this is Keypress event:

    lparameters nKeyCode, nShiftAltCtrl
    if nKeyCode = 13
      NODEFAULT && prevent default base code - acts as if [ENTER] not pressed
      Keyboard "{TAB}" && replace it with [TAB]
    endif

    object sender is "this". Eventarguments are 2 int arguments. Well I should stop trying to make analogy - they're not very same:)

    In C# you add a method like:
    private double getBalance(...) {...}

    and a property:
    public string MyProperty { get;set; }

    In VFP you add a new method via menu in designers (ie: Form-Add method). If not using designer it's simply a new procedure in class code:

    define class myForm as Form
    add object myTextbox as TextBox

      Procedure Init && Form.init
      *...
      endproc

      Procedure myTextBox.Click && form.myTextbox.click
      *...
      endproc
    enddefine

    Properties are added via menu in designer too. In code there are more than one way to add them.

    define class myForm as Form
     myProperty = "InitialValue"
    enddefine

    myObject.AddProperty() && If object supports method
    AddProperty(oObj,...)

    I think I told more than needed:)
    Saturday, September 17, 2005 10:24 AM

All replies

  • I just saved my first creation (a form with a couple of containers and a few controls) and tried to look for a source code file with a notepad. It appears there is nothing like we have in dBASE. It is almost everything like an object code already. It seems impossible to do any editing outside of the designer. A totally different paradigm exists in FoxPro9.

    Maybe it is for the better, I do not know. One has to adjust to what the reality is, not the other way around. Anyway I am waiting for comments from the experts. Perhaps I am wrong on that. Thanks.
    Thursday, September 15, 2005 8:00 PM
  • The source code is in the events, or methods you create for the form.  Each control, label, line, box or whatever has a complete set of OOP options and events where you can type in any code you wish to work on the object or the other objects.

    In the old version of foxpro you could edit the screen file, not anymore.

    We have containers with hierarchy of objects also.  You refer to them with something similar to this:
    Thisform.thiscontrol.thiscontrol.attribute

    For example:
    Thisform.txtLastName.Value = "Higgins"
    will change the value of this textbox to "Higgins"

    Another example:  A label on the form says "Name:"
    thisform.lblLastName.caption = "Last Name:"
    will change the LABEL called lblLastName to "Last Name"
    Thursday, September 15, 2005 8:12 PM
  • Furthermore, you can write custom methods to make things happen in tables or on the form.  We  use custom properties and methods to create custom procedures that can do anything you can dream up.

    Another example would be calculating tax from 2 fields called txtPrice and txtQuantity.  I would create a textbox called txtTaxAmount with a control source of a property called TaxAmount.  Create a property in the form called TaxAmount, another property called TotalCharge, and a custom method called CalcTax.  In the valid event in the txtPrice textbox I call a custom method called CalcTax like this:

    thisform.CalcTax()
    thisform.refresh()



    In the CalcTax method I would write:
    local nTotal, nTaxPercent, nTotalCharge

    *** select setup table to find tax percent stored in table
    select setup
    nTaxPercent = taxpercent

    *** calculate total price and tax
    nTotal = thisform.txtPrice * thisform.txtQuantity
    thisform.TaxAmount = nTotal * nTaxPercent
    thisform.TotalCharge = nTotal + thisform.TaxAmount

    Thursday, September 15, 2005 8:24 PM
  • Thank you. It is interesting.
    Thursday, September 15, 2005 8:34 PM
  • Besides reading the Help file (CHM) which is not bad, you can follow the examples on the Task Pane (one of the toolbar buttons on the extreme right) or you can open it from the Command Box with:

    DO (_taskpane)

    This is an app written in FoxPro itself that gives you functionality, and discoverability of item and examples. It consustes of several sub-apps (panes) on the top toolbar. The one you should look at is Solution Samples. It consists of a TreeView Control with lots and lots of working examples with source code.

    Have fun!


    Also look at the richness of information in the VFP Wiki (also a web app fully written in VFP)
    http://fox.wikis.com/wc.dll?Wiki~ListCategories

    Thursday, September 15, 2005 10:38 PM
  • Technically you can edit the text and settings, just with a DBF BROWSE. Yes, the source code is not in a text file, all the designer source code is stored in DBF files.

    Alternatively you can write code in PRGs (text files if you like). This includes classes, forms, and standard Xbase code.

    The Class Browser tool will export the code from VCX and SCX files into PRG files, but sometimes it writes code which does not run.

    Thursday, September 15, 2005 10:50 PM
  • Thank you very much. It is an amazing new world for me. It is about x1000 wider than the dBASE community. I have a lot to catch up.

    My question is: Is FoxPro a part of .NET formally or it is outside this category?

    Also if I developed a form in Visual Studio .NET browser 2003 can I subsequently open it up in a FoxPro browser and vice versa?

    What does "wiki" stand for anyway?

    Thanks.
    Friday, September 16, 2005 10:16 AM
  • Wiki is "fast" in Hawaian. It is a concept started many years ago by Ward Cunningham. There are countless Wikis on many subjects. They are mainly a repository of information with collaboration from the community.

    Ours is at:
    http://fox.wikis.com/wc.dll?Wiki~FoxProWiki


    The most famous one is Wikipedia:
    http://en.wikipedia.org/wiki/Main_Page


    Visual FoxPro is not a part of .NET in that it does not compile to the CLR. But it can coexist and share information fairly easily through COM Interop

    Sample whitepaper:
    http://www.west-wind.com/presentations/VFPDOTNETiNTEROP/VFPDOTNETINTEROP.HTM

    VFP will work better with .NET in the next release, codenamed "Sedna". See the Sedna Roadmap at:
    http://msdn.microsoft.com/vfoxpro/roadmap
    Friday, September 16, 2005 11:05 AM
  • Thanks again. It is more than helpful.

    I have written perhaps half a million lines of source code in Visual dBASE much of it used in my daily routines but now I have to think about becoming integrated in a larger world.

    VdBASE does have a driver that allows you to read FoxPro tables although I've never used it. I am wondering if FoxPro community somewhere has a driver that reads the native .dbf tables of dBASE? It would allow me to convert many of my database tables to the new format.

    Thanks.
    Friday, September 16, 2005 1:55 PM
  • Hi Alex,

    Usually the drivers to read tables are created and distributed by the people who create the software. You can download VFP's ODBC and OLE DB providers from msdn.microsoft.com/vfoxpro/downloads/updates although you should have them already if you'v installed VFP9.

    To get dBASE drivers you would need to get them from the people who wrote dBASE, or they will already be installed on your machine with the dBASE install.

    The dBASE drivers for FoxPro may not be up-to-date. VFP's ODBC works with all versions of FoxPro tables up to VFP6. After that new features were added to the tables and the data engine that are not compatible with ODBC, and you must access the data via OLE DB. However, tables created with VFP7-9 that do not use any of the new data features are compatible with ODBC.

    You may be able to create tables in FoxPro and use your dBASE drivers to write to those tables from the dBASE environment, therefore moving your data. Another way is to export the dBASE tables to some sort of text file and then import that (there are several ways) into FoxPro.

     

    Friday, September 16, 2005 3:28 PM
  • First of all welcome:)
    You can create forms and other objects using designers or via manual coding. I want to clarify a thing:
    You drop a container and drop controls on it in dBase like in .Net I guess. If so, procedure is a litlle different in VFP. First you rightclick and select edit (or Ctrl+click). Then add other controls. Otherwise other controls you drop are not part of the container.
    I don't know dBase (since dBaseIII+ at least) but a nice feature that I couldn't find in .Net. You can:
    -Create a dummy temp form,
    -drop some controls, arrange and add code to them
    -From menu select 'File\Save As Class' && selected controls create a container class
    Something like .Net's control class library but more flexible than that (maybe in future .Net versions:). Same is available for a single control and/or for compound container type controls like grid,pageframe etc.
    Friday, September 16, 2005 4:30 PM
  • I just checked my ODBC in BDE Administrator (dBASE), although I do not have the latest version of it on this machine (I purposely haven't updated it since I found the newest version really cumbersone), and it lists Microsoft Visual FoxPro VFP Driver Version 4.0. I will check the newest version which is on another machiine at a different location later tonight.

    Also there is Microsoft Visual FoxPro-Treiber 4.0 Driver and Microsoft FoxPro Driver (.dbf) on the same machine.

    All these drivers are part of the DBE engine and come with the subscription. What I am really looking for is to have a driver in the opposite direction.

    Of course, dumping native .dbf dBASE tables into a text file and reading them from there is the last resort. I have this option in the back of my mind. I have used it before when I found indices grossly corrupted or for some other reason.

    Thanks.
    Friday, September 16, 2005 7:50 PM
  • Thanks, that comment on container is very useful.

    Visual dBASE plus affords a lot of control over the source code. Once you've mastered some tricks you can pretty much use it as a tool to mold things your way. Sometimes I go to the source to move controls a little to the right oleft or align them since it is easier to do. If I rearrange them in the designer and save the form the designer's editor will mess things up for me in terms of visual appeal. Many names will be changed, lower case will become upper, etc. Anything but your functions (methods, events) will be molested. Thus it is easier to make changes in the designer, then check the source code right away, notice the metric changes that it introduced, copy pieces of constructor code, shut down the designer but without saving the changes and then go straight to the source file and paste those changes at appropriate place.

    And also all the delegates I always do by hand in the source file--it is so much easier. All event handlers are done by hands. I am using C# terminology here, it is not called this way in Visual dBASE. I do not know how it is called in FoxPro though.

    Friday, September 16, 2005 8:02 PM
  • Terminology is same. Event handler or event code. VFP is not very much different from .Net in that regard. For a control you have many delegates but might use only one - say click - in code.
    If you think of old days, source code was simple ASCII file. Any editing would be spoiled by designer. In VFP however designer generated code is in tables (scx for form, vcx for class and so on). You can 'hack' the scx, vcx and designer loads with your hacks (cool for me - I always liked manual touch rather than using mouse everywhere:) Also I can give you a tip to interact with your design surface during design time manually.
    Suppose you created a checkbox on form, set its font, color etc. Its caption would be something like "Room 1". You want 20 more of these checkboxes lined with 'same left' and only name and caption changes sequentially.
    -Drop a checkbox on form
    -It's selected by default if not Click to select
    -Go to command window and type
    Modify Command[ENTER] && or MC[space][ENTER] - case insensitive
    -Directly code your "builder" there. ie:

    ASelObj(aObj) && Creates an array of selected objects
    ASelObj(aObjFrm,1) && Creates an array which points to the parent container
    loChkRoom = aObj[1]
    loParent = aObjFrm[1]
    loChkRoom.Name='chkRoom1'
    loChkRoom.Caption='Room 1'
    For ix=2 to 20
      loChkRoom.CloneObject('chkRoom'+Ltrim(Str(m.ix)))
      With Evaluate('loParent.'+'chkRoom'+Ltrim(Str(m.ix))) && obj ref of clone
       .Caption = "Room "+Ltrim(Str(m.ix))
       .Left = loChkRoom.Left
       .Top = loChkRoom.Top + ( loChkRoom.Height + 2 ) * (m.ix - 1)
       .Autosize = .t.
      EndWith
    EndFor
    loParent.Refresh

    -[Ctrl+A] to select all code and rightclick "Execute Selection"
    (It executes selected code but doesn't save anywhere unless you say so - sort of same as select/copy a piece of code from anywhere and execute "ExecScript(_cliptext)" in command window)

    This sample doesn't show its power but  know that basically it's the same approach "builders" use. With this I rarely need to hack scx myself. For example, in designer properties like class/classlibrary are readonly. You can change them in code hacking scx or this builder approach too works:) - Disclaimer: Hacking forms/classes should always done with a backup and at one's own risk. If you do don't forget to compile.

    A final note (I was confused with it when I first stepped into VFP3 OOP from 2.x):
    There are methods and events. They're practically the same thing - "procedure" or function. Events are implicitly invoked (while you could explicitly invoke too) as a response to something, methods need explicit calls. (events are C# delegates which you subscribe by default). IOW in C# it looks like:

    private void myButton_click(object sender, EventArguments e) {}

    If you dblclick an object you get its events/methods code window (dropdown at top right shows the event, left shows the object - so left "myButton", right "Click")

    If you code something it's executed at runtime followed by deafult base code of event. A typical example of this is Keypress event:

    lparameters nKeyCode, nShiftAltCtrl
    if nKeyCode = 13
      NODEFAULT && prevent default base code - acts as if [ENTER] not pressed
      Keyboard "{TAB}" && replace it with [TAB]
    endif

    object sender is "this". Eventarguments are 2 int arguments. Well I should stop trying to make analogy - they're not very same:)

    In C# you add a method like:
    private double getBalance(...) {...}

    and a property:
    public string MyProperty { get;set; }

    In VFP you add a new method via menu in designers (ie: Form-Add method). If not using designer it's simply a new procedure in class code:

    define class myForm as Form
    add object myTextbox as TextBox

      Procedure Init && Form.init
      *...
      endproc

      Procedure myTextBox.Click && form.myTextbox.click
      *...
      endproc
    enddefine

    Properties are added via menu in designer too. In code there are more than one way to add them.

    define class myForm as Form
     myProperty = "InitialValue"
    enddefine

    myObject.AddProperty() && If object supports method
    AddProperty(oObj,...)

    I think I told more than needed:)
    Saturday, September 17, 2005 10:24 AM
  • Thank you very much. This comparison is very helpful.
    Saturday, September 17, 2005 12:35 PM
  • Thank you, it is extremely helpful.
    Saturday, September 17, 2005 8:44 PM
  • Alex,

    VFP does not have two tools like dBase has. Forms and classes that are created in the form/class designer use a normal VFP table to hold the property values and method code. Forms use scx/sct files, classlib use vcx/vct. So we don't have a PRG that you can open and edit and see those changes the next time you open the designer. If you did that heavily in dBase you are going to be in for a mindset change. Honestly I don't really have a desire to ever have to wade through pages and pages of text compared to working with the property sheet and a method window or two.

    You can use the ClassBrowser to output code for classes or forms, but it's fundamentally only meant to be a sort of documentation tool. The generated code will not execute if any containership is involved.

    The kinds of stuff you'd go into the code to commonly edit in dBase we either use builders or subclasses of the controls.

    VFP has several container classes. A Form is a container. PageFrames contain Pages and the Page can contain controls. Grids contain Columns and Columns contain a Header and a control like Textbox. You have to put the container into edit mode to be able to drop controls into the container as opposed to onto the container. You can rightclick and select edit or select the container from the object dropdown list on the property sheet.

    Another example of where having the design surfaces using native tables is beneficial. Say you've designed a couple of forms using the native VFP controls and you find a problem like the default Autosize of labels is .F. and you are constantly having to change it every time you drop a label on a form. So you create your own first level subclasses of all the VFP controls to "fix" these shortcomings. You can write a small chunk of code that will USE TheExistingForm.scx and do a REPLACE command to change all the VFP baseclass labels to your own subclass.

    df - Microsoft FoxPro MVP
    Monday, September 19, 2005 3:07 AM
  • David thanks. it is very helpful.

    Aside from the design problem which seems to  have been settled I have another question which I think I asked at the head of this thread: it was about the drivers. Anyhow I am trying to figure out how to transfer my dBase database tables to either FoxPro9 or MS SQL databases. What I found so far is that the dBase DBE has a few drivers which seem to have been written by MS that are dBase related. Also I discovered somewhere in the MS library the existance of similar drivers. I haven't figured out how to use them though.

    Now I have a pointed, specific question. In the MS Visual FoxPro Project Browser if you click on Tools-->Options-->General <tab> you will see an option checkbox: "dBASE compatibility." I checked it in and started attempting to open some of my .dbf tables. I am getting two error messages (1) It is not a table (2) Access is denied. I could not open a single table so far.

    I cannot figure out why different tables give me different error messages. To my dBase engine they are very similar, differing only in the number of fields.

    Could you comment on this please?
    Wednesday, September 21, 2005 4:33 PM
  • Well, with all your meaningful help I am getting more and more mobile in VFP environment. I am creating tables and databases and have a clear idea now how to handle classes, etc.

    As far as the data transfer story what I will most likely end up doing is to dump my tables one by one into text files with some meaningful delimiters between fields, pehaps some unprintable ASCII characters and then read the text files into VFP tables I am now creating. It seems to be the simplest thing to do as I can see.

    Thanks.
    Wednesday, September 21, 2005 5:17 PM
  • Alex,

    That dBase compatibilty checkbox probably ain't what you want. *g*

    It controls the behavior of a few functions and commands that FoxPro implemented differently than dBase did. Look at the help file for SET COMPATIBLE.

    As to the dBase table access I don't have recent experience. I left the dBase world back while we were still waiting for Borland to release a Windows version.

    The different error mssages may pertain to the new table integrity checking that VFP9 does. Can you create a remote view via ODBC to the dBase tables and then append from the view into the new VFP versions of the tables?

    I don't know how much data you have to move around it may be possible to push the data out to something like a CSV or SDF file with dBase code and then read that file into VFP?
    Thursday, September 22, 2005 12:24 AM
  • Thank you for pointing this out to me, David. This is what FoxPro help says about dBase tables. It is very encouraging but still cryptic.

    PROMPT | NOPROMPT

    These options determine whether Visual FoxPro displays a dialog box when you open a dBASE table containing a memo field. Include the PROMPT option to display the Convert Memos dialog box. If you open a dBASE IV table containing a memo field, Visual FoxPro by default displays the Convert Memos dialog box, which enables you to convert the dBASE memo file to a Visual FoxPro format. You must convert the memo file to a Visual FoxPro format to open the table in Visual FoxPro. If you include NOPROMPT, the Convert Memos dialog box is not displayed when you open a dBASE IV table containing a memo field. The dBASE memo file is automatically converted to a Visual FoxPro format.

    I am wondering what the default here is? But regardless of the dialog box convenience which is collateral the meaning of the above paragraph is, in my opinion, that you can open those tables, at least dBASE IV tables. Some other fields have been added to the armament since and maybe this is the problem at this point.

    I will consider CSV and SDF file conversion too.

    Thanks.
    Thursday, September 22, 2005 12:14 PM
  • Alex,

    I don't know that FoxPro has kept up with any dBase changes to dbf file structure or new data types that have been introduced beyond dBaseIV.

    The PROMPT option only deals with dbt to fpt conversion. The default value is OFF. The prompt/noprompt optioin is independent of the other values. If memory serves PROMPT is the default behavior for dbt conversion.
    Thursday, September 22, 2005 2:54 PM
  • Alex,
    AFAIK VDbase 5.x tables can be imported with Access (unless VDbase don't have driver already that you know). If you can import there check universalthread.com FAQ section how to convert an MDB to a VFP dbc. 

    http://www.universalthread.com/wconnect/wc.dll?LevelExtreme~2,84,14,8039
    Thursday, September 22, 2005 5:09 PM
  • You are absolutely right and I have done it. If I am not mistaken some of the information gets lost, however, if my recollection is correct.

    i did it as recently as 2 years ago on Visual dBASE tables before the last upgrade.

    Thanks.
    Friday, September 23, 2005 1:45 PM