Results 1 to 3 of 3
  1. #1
    Join Date
    Dec 2003
    Location
    Oklahoma
    Posts
    17

    Unanswered: Coming from FoxPro - help!

    I am a FoxPro programmer needing to switch to Access. 2 questions...

    1) Does anyone know of any resources that explain Access to a FoxPro user?
    2) My immediate mental block is not knowing which table I am adding a record to because I feel like I need to set the current database to the table I want. How do I determine which table I am working on? When I add a record using an add button, how do I know which table I am adding to?

    Thank you for any help! I've programmed for years, but all of a sudden I feel pretty ignorant!

    WHardy7

  2. #2
    Join Date
    Dec 2003
    Location
    Toronto, Ont. Canada
    Posts
    238

    Re: Coming from FoxPro - help!

    Originally posted by WHardy7
    I am a FoxPro programmer needing to switch to Access. 2 questions...

    1) Does anyone know of any resources that explain Access to a FoxPro user?
    2) My immediate mental block is not knowing which table I am adding a record to because I feel like I need to set the current database to the table I want. How do I determine which table I am working on? When I add a record using an add button, how do I know which table I am adding to?

    Thank you for any help! I've programmed for years, but all of a sudden I feel pretty ignorant!

    WHardy7
    Welcome... I know how you feel... When I first started working with Access it took me a while to figure out the thing... and VBA... lol...

    Which verion of Access are you switching to?

    1) No idea... Wish I could help...
    2) Well that sort of depends.... There are different ways to do that...

    Are you adding a record from a Form?... If so, if the Form recordset is bound to the table you want to add to, and the controls on the form are also bound to it... it can be as simple as entering the data and tab-ing to the next record...

    Or if you are wanting to add records programmatically ... you can use DAO or ADO... I've worked with Access 97 for years now so I'm way more comfortable with DAO...

    With DAO you would delare object variables... and use their properties and methods to do what you want... To add a record you would declare a database and a recordset... Then use the recordset's AddNew and Update methods to add the record...

    Here's a little sample function I got from Access help:

    Function AddName(rstTemp As Recordset, _
    strFirst As String, strLast As String)

    ' Adds a new record to a Recordset using the data passed
    ' by the calling procedure. The new record is then made
    ' the current record.
    With rstTemp
    .AddNew
    !FirstName = strFirst
    !LastName = strLast
    .Update
    .Bookmark = .LastModified
    End With

    End Function

    HTH Somewhat...

  3. #3
    Join Date
    Oct 2003
    Posts
    706

    Wink

    Well, there's really no good way to explain it. Maybe a little background will help in the transition. Come, sit down, take a strong drink of your favorite imbibement .. take another swig .. and another (you'll need it) .. .. and let us begin.

    Systems like FoxPro were architected at a time when computer resources were absurdly limited, and to do anything at all you had to write a program to do it. The DBMS basically gave you a more expansive programming language to work with, and that is all.

    By comparison, MS-Access was architected when computer resources could reasonably be assumed to be in surplus. It was reasonable to construct a full-featured implementation of SQL right there on the desktop, as well as a very sophisticated "main program" to run the whole user experience. And this is exactly what they did.

    So, to get a report, for example, you never "write a program" to do it. You simply design the report, setting "properties" of various things to tell those things exactly how they should work in this case, and when you "open the report," MS-Access does (perhaps) all of the work for you. You are under no obligation to "program" anything, and usually you don't. ... program ... anything.

    The same is true of "forms" (windows). They're there; they work by themselves; you didn't write any code to make it; you can't write code to build one programmatically; they contain objects chosen strictly from the MS-Access cadre of available objects (or OCXes); and that's that. "Them's your choices."

    Your choices are very limited, but you can use them very fast.

    (Kindly note: I come not to praise Caesar, nor to bury him; merely to describe him and merely as I see it.)

    Where "programming" comes into play with this system, then, is really a matter of "programming by exception." You write code only to intervene in what the MS-Access main-program is set up to do already. The system will call "event handlers" provided in your code, if they exist, to handle specific well-defined cases. Otherwise, it simply does what it's already designed to do in that case.

    You will find, with MS-Access vs. FoxPro, that you actually write only a tiny percentage of the code that FoxPro would have demanded (even if FoxPro had generated the code for you). You will find that your overall choices are a lot more limited and that you must find a way to get the job done strictly within the scope of what MS-Access has to offer. However, once you stop ranting and railing about that, you'll find that jobs can often be done much quicker.

    In FoxPro, the "kernel" of the system is comparatively small and the typical application wraps many layers of user-written (or user-writeable) software around that.

    In a system like Access, the "kernel" is large, monolithic, provided by the vendor, and not available for inspection. A typical application "plugs in" a small amount of software to that, at the event-interface points provided.

    Now... Aren't you glad it's Christmastime and you'll have plenty of time away from work in which to look for another job?
    ChimneySweep(R): fast, automatic
    table repair at a click of the
    mouse! http://www.sundialservices.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •