Help with Paradox 9 table schema

wrote:

> This OPAL language sounds interesting. Do you know if there's any way
> I can integrate this into a Borland C++Builder application?:Where else
> can I learn abouit OPAL? I've never even heard of it. There doesn't
> even seem to be a Wikipedia article on it.

Check out the Programming section of www.thedbcommunity.com for lots of
articles on ObjectPAL. I'm unaware of anyone utilizing ObjectPAL outside of
Paradox or Paradox Runtime.

In a nutshell, ObjectPAL is sort of a non Object-Oriented version of
ObjectPascal, but with a rich set of built-in classes for manipulating any
table, field, or UI element of a form or a report.

--
Larry DiGiovanni

Deprecated means no longer used (going forward) and no longer
supported (by the company that created/owns it).

Embarcadero is the company that bought 'Borland'. All the development
tools, anyway. Not sure if they bought the name as well.

The remainder company that WAS Borland is delving into Witchcraft, or
Gaea worship .. or something.


------------------------------
Tony McGuire

> what's "embarcadero"?

the company that bought CodeGear, the spin-off that was Delphi, etc..

--
Steven Green - Myrtle Beach, South Carolina USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales

Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Sports Memorabilia and Trading Cards

wrote in message
news:909ee1d4-8c3f-4970-b2e8-08cdd4ab6007-at-s50g2000hsb.googlegroups.com...
> On Aug 18, 7:27 pm, "Steven Green" wrote:
>> might just be a timing issue.. overall, the borland groups are great..
>> the
>> paradox group evolved from borland groups, when paradox was part of
>> borland.. right now, all the old borland groups got axed, and the new
>> embarcadero groups just started as the replacement..
>
> what's "embarcadero"?

On Aug 18, 8:34 pm, "Tony McGuire" wrote:
> Deprecated means no longer used (going forward) and no longer
> supported (by the company that created/owns it).
>
> Embarcadero is the company that bought 'Borland'. All the development
> tools, anyway. Not sure if they bought the name as well.
>
> The remainder company that WAS Borland is delving into Witchcraft, or
> Gaea worship .. or something.
>
> ------------------------------
> Tony McGuire

This is interesting. So does this mean that C++ Builder and Delphi are
becoming obsolete?

> This is interesting. So does this mean that C++ Builder and Delphi
> are
> becoming obsolete?

Obviously, not if Embarcadero can help it.

And there are even a couple of people who are hoping they'll do
SOMETHING that will help Paradox.


--
------------------------------
Tony McGuire

On Aug 18, 8:07 pm, "Larry DiGiovanni" wrote:
> Check out the Programming section ofwww.thedbcommunity.comfor lots of
> articles on ObjectPAL. I'm unaware of anyone utilizing ObjectPAL outside of
> Paradox or Paradox Runtime.
>
> --
> Larry DiGiovanni

OK, so after playing around with ObjectPAL for about an hour, could
someone show me how to create a cascading referential integrity link
on a field TransactionID in a parent table called Transactions and a
child table called TransactionDetails? In one of those articles on
www.thedbcommunity.com called "Do It Yourself Referential Integrity",
the author declines to show a working code sample because it is
unreliable. Well, I'd still like to know how. I don't care if it's
unreliable.

Much here that is new to me! Like you, I use a lot of sub-directories for
self-contained child databases -- so everything I use is always aliased,
and therefore ends up hard coded.

Jim Hargan

On Tue, 19 Aug 2008 07:41:25 +1000, Robert Molyneux wrote:

> Jim Hargan wrote:
>
>>
>> Now for the problems. Paradox is the Tounces of the RI world. It does it --
>> just not very well. The big problem is that the table directory paths are
>> HARD CODED into the structure, right down to the drive letter. If you move
>> either table, your whole application breaks. This makes Paradox RI
>> effectively undeliverable. For a one-person standalone application it does
>> what you want -- until you decide to buy a new computer. Then you have to
>> EXACTLY duplicate the drive and directory structure on the new machine. And
>> don'd even THINK about rearranging your hard drive.
>>
>
> Just for the record, this is not true.
>
> All tables that have RI relationships must be in the same directory, and
> the path is irrelevant.
>
> However, lookup tables can potentially span directories - you could have
> a directory for handy lookup tables, used by one or more applications,
> with the main tables located in other directories.
>
> Then, you can use Paradox's excellent aliases (hugely useful concept) to
> link tables to :MyLookups:LookupOfPostCodes and so on.
>
> Trouble is, when you relocate the tables, and redefine the aliases, you
> discover that the aliases have been converted into hard-coded paths, and
> nothing works anymore - a bit like M$ Work when it breaks all linkages
> to sub-documents and other objects if you move a document.
>
> So you can use RI and lookups very easily, but all files related like
> this must be in the same directory.
>
> In my case, I have lots of directories for different "sub-databases",
> and I replicate some lookup tables that are required to be used within
> multiple sub-databases. A minor administrative annoyance.
>
> This is not to say that RI actually works very well. Lookups do, though,
> to enforce allowable sets.
>
> BTW: Metadata about table properties and linkages are held in files
> Table_Name.VAL.
>
> If you delete or rename .VAL files, all constraints on master-detail
> data actions are removed, so you can do stuff like deleting master
> records before deleting detail records, or adding detail records before
> adding master records. Especially useful for handling groups of tables
> that have cross-linked relationships.
>
> You can rename them, do the business, then rename them back again,
> without losing metadata.

Robert,

The main deal-breaker for me with Pdox's R.I. was if a table became corrupt.
When Tutil32 rebuilt it, it also included the backed up 'copy of' table
in the new R.I. chain.

This would cause table open errors, since obviously, the backed up table
was corrupt to begin with.

The only way I found to fix this was to delete the VAL file & rebuild it.

Jim Moseley

Jim Hargan wrote:
> Much here that is new to me! Like you, I use a lot of sub-directories for
> self-contained child databases -- so everything I use is always aliased,
> and therefore ends up hard coded.
>
> Jim Hargan
Hi Jim,

If you change the working directory to the child database, when you do
the linkage of tables for lookups you do not need to use aliases. From
then on, Paradox simply assumes that the main table and the lookup table
are in the same directory, and does not store the pathway.

Then you can reset the working directory, and still reference the tables
using aliases, with all relationships working correctly.

If you do use aliases, you can move the database from one system to
another provided that you can map the location to the same letter on the
new system as on the old. For example, I used to have all my tables
nicely set out in directories, heavily cross-referenced with aliases,
and all saved in Q:\Database_Directory. So long as I could snaffle the
Q:\ mapping there was no problem. But of course, generally this is not
acceptable.

Some years ago I suggested in this forum that (a) aliases were a really
great concept, and (b) the way they were turned into hard-coded paths
was a really great boo-boo - and got all sorts of strange responses...

In the Amiga OS (now THERE was a great OS) you could define symbolic
paths that all software including SuperBase (quite a good RDBMS) could
use - so you could have My_Main_Database and My_Handy_Lookup_Tables and
so on configurable. The nearest that M$ OS has are things like
MyDocuments and shares - but you really need to be able to define shares
within shares.

It would be handy to have a "directory" / "module" concept in CS
databases - that is, be able to put tables into logical groupings within
one CS database - maybe already there?

> My problem is: your approach is the result of a well-thought-out design.

don't you just hate that? (vbg)

--
Steven Green - Myrtle Beach, South Carolina USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales

Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Sports Memorabilia and Trading Cards