Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Database or plain tables? 1
- Thread starter BlindPete
- Start date
-
1
- #2
ChrisRChamberlain
Programmer
Pete
Long table names
Comments for each field, table and database
Long field names
Captions for fields that display in Browse windows and Grid Column headers
Default values on fields
Primary and candidadte fields
Field-level rules and record-level rules
Triggers
Persistent relationships between database tables
Stored procedures
Connections to remote data sources
Local and remote views
IMHO, it's a lot simpler using free tables unless you really need those features.
Chris [sig][/sig]
Long table names
Comments for each field, table and database
Long field names
Captions for fields that display in Browse windows and Grid Column headers
Default values on fields
Primary and candidadte fields
Field-level rules and record-level rules
Triggers
Persistent relationships between database tables
Stored procedures
Connections to remote data sources
Local and remote views
IMHO, it's a lot simpler using free tables unless you really need those features.
Chris [sig][/sig]
To add to Chris' last comment: its one more thing to go wrong.
Long field names are nice, and may itself be reason enough. The VFP RI builder has a reputation for having glitches and not the best performer in the world.
If you really need robust engine-level referential integrity enforcement and constraints, AND you have the flexibility, you might be better served by using MSDE or SQL Server. [sig]<p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br> [/sig]
Long field names are nice, and may itself be reason enough. The VFP RI builder has a reputation for having glitches and not the best performer in the world.
If you really need robust engine-level referential integrity enforcement and constraints, AND you have the flexibility, you might be better served by using MSDE or SQL Server. [sig]<p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br> [/sig]
csr
Programmer
- Jul 20, 2000
- 507
Just need to add my 2cents ...
I would strongly argue against using databases unless you have some definite need for a particular feature. Databases get "nasty" about a few things that were formerly simple. I can't remember precisely what they were now because I have stopped using them. But I remember having lots of frustration with things that were just a normal part of my programming in the past.
They (databases) have some nice concepts ... granted ... but the frustration outweighed the gains in my book. AND .. I really have no particular use for the features they provide.
[sig]<p>Don<br><a href=mailto:dond@csrinc.com>dond@csrinc.com</a><br><a href= > </a><br> [/sig]
I would strongly argue against using databases unless you have some definite need for a particular feature. Databases get "nasty" about a few things that were formerly simple. I can't remember precisely what they were now because I have stopped using them. But I remember having lots of frustration with things that were just a normal part of my programming in the past.
They (databases) have some nice concepts ... granted ... but the frustration outweighed the gains in my book. AND .. I really have no particular use for the features they provide.
[sig]<p>Don<br><a href=mailto:dond@csrinc.com>dond@csrinc.com</a><br><a href= > </a><br> [/sig]
- Thread starter
- #5
Thanks all!
I toyed with them one day a few years ago. I didn't see much advantage to them then (made my desktop lock several times too). I see little has changed.
Are DBC's required for ODBC with another datbase format like Access? All the documentation examples I have seen use DBC. I'd rather not if I don't have to. [sig]<p> Pete<br><a href=mailto:blindpete@mail.com>blindpete@mail.com</a><br><a href= > </a><br>What your mother told you is true! You will go blind! (from moonshine anyway)[/sig]
I toyed with them one day a few years ago. I didn't see much advantage to them then (made my desktop lock several times too). I see little has changed.
Are DBC's required for ODBC with another datbase format like Access? All the documentation examples I have seen use DBC. I'd rather not if I don't have to. [sig]<p> Pete<br><a href=mailto:blindpete@mail.com>blindpete@mail.com</a><br><a href= > </a><br>What your mother told you is true! You will go blind! (from moonshine anyway)[/sig]
If you want to use persistent remote views, which require
A) a storage place (the DBC); and
B) a named connection (which is typically also stored in the DBC)
then you'll need one.
I'm writing an app where, due to security reasons, I don't want a persistent named connection, so I am using SQLSTRINGCONNECT() along with non-updatable remote views; I won't need a DBC. [sig]<p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br> [/sig]
A) a storage place (the DBC); and
B) a named connection (which is typically also stored in the DBC)
then you'll need one.
I'm writing an app where, due to security reasons, I don't want a persistent named connection, so I am using SQLSTRINGCONNECT() along with non-updatable remote views; I won't need a DBC. [sig]<p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br> [/sig]
I'll send you my attempt via e-mail and if you can see where I went wrong, or where your approach and my approach differ, I'll make a FAQ of it and give you all the credit!
What I'm doing now, and what works, is I make a local cursor from the primary SQLS table using SQLEXEC(). I then bind my controls' ControlSource to the appropriate columns. Upon pushing cmdSave, I roll through the cursor and build an INSERT or UPDATE statement, and SQLEXEC() it. Works fine, but I feel uneasy about the handling of UPDATE - because I'm not really checking to see what's changed. This is the one area where an updatable remote view does a whole lot of the grunt work for you, and does it much faster than we can do it in Fox code.
To explain why I'm going through all this: persistent remote views require storage in a DBC, and (more importantly) require a persistent named connection stored in the DBC. This named connection must either contain the username/password, or must point to a Windows DSN that contains the username/password.
Since DBCs are normally shared, and decent database security forbids sharing of usernames, and storing username/passwords anywhere is not a good idea anyway, named connections are out - and, therefore, so are persistent (stored) updatable remote views.
The neat trick would be to create a local view/cursor via SQLEXEC(), then force it to be updatable - and this is what Vlad thinks he has found the secret ingredient for. [sig]<p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br> [/sig]
What I'm doing now, and what works, is I make a local cursor from the primary SQLS table using SQLEXEC(). I then bind my controls' ControlSource to the appropriate columns. Upon pushing cmdSave, I roll through the cursor and build an INSERT or UPDATE statement, and SQLEXEC() it. Works fine, but I feel uneasy about the handling of UPDATE - because I'm not really checking to see what's changed. This is the one area where an updatable remote view does a whole lot of the grunt work for you, and does it much faster than we can do it in Fox code.
To explain why I'm going through all this: persistent remote views require storage in a DBC, and (more importantly) require a persistent named connection stored in the DBC. This named connection must either contain the username/password, or must point to a Windows DSN that contains the username/password.
Since DBCs are normally shared, and decent database security forbids sharing of usernames, and storing username/passwords anywhere is not a good idea anyway, named connections are out - and, therefore, so are persistent (stored) updatable remote views.
The neat trick would be to create a local view/cursor via SQLEXEC(), then force it to be updatable - and this is what Vlad thinks he has found the secret ingredient for. [sig]<p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br> [/sig]
- Status
Similar threads
