XBase programmer needs help understanding Access

  • Thread starter Thread starter JAF
  • Start date Start date
Thanks for both of your posts.

Can someone give me a small sample of the code for fast indexing and
relational work?
Click to expand...

Just to make an additional emphasis to Gunny and David's excellent
suggestions:

Access is NOT a flawed implementation of FoxPro.

Both FoxPro and Access are very capable relational database tools.

But they are *DIFFERENT* relational database tools.

Insisting on using Access as if it were FoxPro, or using it slavishly in
exactly the same way that one would use FoxPro, is a recipe for frustration.

John W. Vinson [MVP]
 
Hi, Larry.
But, as we know, one of the fastest routes to complete frustration is to
expect a different product to work, or be used, the same as some other one
with which you are familiar.
Click to expand...

I can't argue with you there. I can't. However, there's a flip side that I
experienced when I first worked with Access. While I'm a big fan of Access
now, but it wasn't always so. I bad-mouthed Microsoft, the designers of
Access, the Access programmers, and the help file creators every day and
night because of the frustrations regarding things that didn't work. (Okay,
the majority of the time it was because I didn't understand how it should
work because either I misinterpreted the help files or I just didn't know
enough about Access -- and couldn't find the pertinent help topics in the
help files -- but the rest of the time the help files had bonehead errors or
Access gave me error messages that were outright lies). Due to the
tremendous frustrations, I would have quit very early in my Access developer
career had I not had that comfort zone of being able to use code to overcome
many of the hurdles.

Also, the upside to coding is that code can be reused, over and over. And
running automated code is much faster than doing it manually through the GUI
and less prone to human error. (Well, after the code has been debugged and
tested, that is.) And in my case, I discovered a lot more things about
Access in a very short period of time than most people do because I was
using code instead of the GUI for certain things. (Okay, a _lot_ of things,
but I became very familiar with the Access object library, VBA, and DAO
fairly quickly because of it.)

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
Blogs: www.DataDevilDog.BlogSpot.com, www.DatabaseTips.BlogSpot.com
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.
 
Primary keys, foreign keys, and indexes aren't against the basic
philosophy of a relational database, which includes Access.
Click to expand...

You mean "which includes *Jet*."
I agree that the GUI
interface is soooo much easier to learn with, but his question,
"Can someone give me a small sample of the code for fast indexing
and relational work?" indicates that he wants the equivalent code
for the commands he's used to in FoxPro, not dragging, pointing,
and clicking on items in the windows in Access.
Click to expand...

The guy needs to create some reports with sorting and subtotalling.
I don't see that your instructions help him.

In fact, I think the whole concentration on the term "relationships"
is wrongheaded. It's imported data, and any RI is going to be in the
imported data. What is needed is *joins* and relationships are
irrelevant (and may not even be creatable, if the data doesn't
comform to the requirements needed to establish relationships).
I and most other Oracle professionals (at least those of us with
formal training) learned relational database design through SQL,
Click to expand...

And that's not *Access*.

Which was my point.
not through a GUI
interface, and I suspect others who take formal courses using
other client/server databases also either learn the SQL first or
else the SQL behind the commands when working with the GUI
interfaces of their database tools, too.
Click to expand...

But the guy needs to learn how to use *Access*, and all you're
teaching him is SQL. If he used Access first of all, he'd be able to
pretty much ignore SQL for now and be able to still get the job
done.
I won't hold that against you. ;-)
Click to expand...

I realized after I posted that I've executed lots of MySQL DDL
statements.
I will always have a very high respect
for your database skills, which are considerable. Most Access
database developers never have a need to use DDL, because the GUI
has more than enough tools for the job. But Jet SQL can do the
job, too, and is often more familiar to others whose backgrounds
include using other relational databases.
Click to expand...

But not your present correspondent, who does *not* know SQL.
 
Can someone give me a small sample of the code for fast indexing
and relational work?
Click to expand...

There is no code needed.

Which is the whole point that people are trying to make to you.
 
WRONG
in Access your relationships are there until you split the database

then they're GONE

RI is not possible with SQL Server
 
FoxPro has been depecrated

stfu kid



Tom McNally said:
Having used both Foxpro and Access for different projects, for larger
files (200K+ rows) I found Foxpro to be more efficient. Access bombs
when it gets to be near 1Gig in size, and it "grows" as you run
queries and do imports/deletes etc, so you need to keep track of size
and do more housekeeping than you would in Foxpro.

You have about the same amount of tools and access methods at your
disposal but they're implementation is different: MS Access is VBA and
GUI-based while Foxpro is a derivative of its X-based predessors.

The programming and relationship modelling is more "elegant" in
Access, so if you're designing something that may have lots of reports
and need to have user access limited or assisted with form controls,
Access is far superior.

For quick and dirty analysis, or the manipulation large files, or
Oracle, SQL Server or Sybase imports, then I'd stick with Foxpro.

Indexing. MS Access is more geared to GUI-based tools, so for examp if
you have a Foxpro file that you want to import into an MS Access
database and add a new index (it should import existing indexes I
think), or create a new table, you use the Import feature from the
File | Import menu, which is pretty straightforward. Then you can go
into the design mode of the imported table and index (unique or
compound or multiple) whatever fields you desire or that would be
important for joins to additional tables. Depending upon size of
table (and # of fields or indexes), initial index is pretty fast. The
relational model is just a matter of opening up the relationship
"window" and dragging the simliar fields from one table to the
dependent or equal field of the other table(s) --
Table1.empID->Table2.empID. Foxpr and your options are inner joins,
left/right (one to many), and the other standard SQL fare.

Check out http://www.mvps.org/access for help getting started.
Click to expand...
 
SQL Server should be used; even if it is a single record and a single user

SQL Server is EASIER development; more powerful
only a retard stuck in the 90s would use Access MDB

open up Access, File, New, Project (existing data)
 
David

STFU Access can't work with 100k records.

I've done it and I grew sick and tired a decade ago
 
Access _IS_ a flawed implementation of SQL Server

there is no 'different relational needs'

there are crapppy ass programmers that use obsolete databases.. and there
are SQL Server developers
 
Back
Top