Overview of Paradox database structure and architecture

Hi, Roger,

> For many of us, these newsgroups have been a resource for learning, problem
> solving and giving back to our community. They have generally been civil
> and respectful and non-judgmental.

I disagree.

In general, they have been EXCELLENT, IMO. <g>

> You may not always like the question or the implication of the question or
> the questioner. If you have a response that doesn't add value to the
> discussion then perhaps it should be left unsaid.

[Perhaps the following should also be "left unsaid"! <g>].

However... if a query appears which makes one's blood boil, or which
might result in a blatant abuse of the generosity and helpfulness of the
regulars here (or of others), it's real hard to remain silent!

Whistle-blower?

More common examples occur on the programming NGs (or Math, etc), where
students/cheats are hoping to get their assignments done by "experts".
Usually, someone exposes the abuse, which alerts the regulars, dissuades
most of them from assisting, and, hopefully, results in the student
doing the homework "properly".

Not to even mention that the helpful folks are rarely thanked for their
help, and the helped folks will never, ever, help others in the same NG,
in a similar fashion.

Obviously, anyone can still choose to be as helpful (or unhelpful) as
one wishes... But, overall, I think there are times when "alerts" are
relevant.

- Mike
 >> Stay informed about: Overview of Paradox database structure and architecture 

Hi Mike,

I hope you are agreeing that "[the NG] have generally been civil and
respectful and non-judgmental." and want to add that they are "EXCELLENT."
If forgetting that superlative caused anyone to feel slighted, I apologise.
I agree with Mike wholeheartedly.

The support, ideas and community we have shared have helped us all and I
very much appreciate it.

I respect everyones's right to their opinion and everyone's right to have a
little rant when passions heat up. I can get cranked up as well as anyone.
We can still have our say, and I agree that we should when the subject moves
us, but I hope we try to maintain a level of civility and respect.

The originator of this thread seemed to jerk quite a few chains with the
wording of his initial question. It was his inappropriate responses that
escalated the tone of the discussion. Perhaps he should have just gone
away.

As to "Alerts", I also agree. Liz opened a conversation a while back about
which questions to ask when interviewing a programmer. It was a great read.
I hope the person interviewing this fellow knows how to see past this
illusion. I think the most amusing part of this whole discussion was why
someone was looking to go from Paradox to Access in the first place.

Thanks, Mike, for your feedback and perspective. What an interesting
community!

Roger
 >> Stay informed about: Overview of Paradox database structure and architecture 

On Wed, 30 Jul 2008 11:20:43 -0400, Dennis Santoro wrote:

> If you mean the internals they are not public (nor published AFAIK). If
> you mean how does paradox work or how are tables structured, thats a lot
> to learn. As for sending to your private mail, that isn't how the groups
> work.
>
> Feel free to ask questions here. We'll try and answer them here.

I just tuned in, Wow!
He really wound you all up

Does this hold the record for the longest thread on the group?

Seriously, I have had great help here (esp from Liz, Tony, Dennis) and I
am sure I speak for many visitors passing through with queries small and
complex.

Without you I wouldn't have two good apps going. And I'm really
glad I stayed the course with Pdox. We went through the start of the
academic year using my automated used student book purchase app with 4
stations (well, hardly a record) manned by students with a few hours
minimal training and doing their best to break everything, and we did not
have a single blip. Backed up and used my Chimney Sweep every day as a
precaution. I wish I had more time to play with my pdox and make it all
neat and tidy. One day I'll retire to my desert island and do just that.

Anne
casual coder, remember?

>
> Denn Santoro
> President
> Resource Development Associates
> http://www.RDAWorldWide.Com
> Offices in the United States and Germany
> Providing solutions to health care, business, governments and
> non-profits since 1982
>
> Dominick DiMantova wrote:
>> Hello, I would like to know if I can get an overview of a paradox database
>> structure and architecture? I'm applying for a migration position that requires
>> familiarity with paradox database structure. Can someone help me by sending
>> documentation to my email account, dominickdimantova RemoveThis @comcast.net? I really
>> would appreciate this.
>>
>>
>>
 >> Stay informed about: Overview of Paradox database structure and architecture 

On Tue, 05 Aug 2008 23:14:02 +0200, Anne Wainwright wrote:

> Does this hold the record for the longest thread on the group?

At 93 responses (ooops! 94!), not even close. Rodney's post of Dec 3, 2004
in Off-Topic, entitled "Who Voted for Kerry", garnered 211 responses.

--
Jim Hargan
 >> Stay informed about: Overview of Paradox database structure and architecture 

Juri,

Thanks for this - see comments inline @@@

BTW - I appreciate this thread as a chance to see how others put
applications together - which is what "architecture" means...

modri dirkac wrote:
>> My app has 420 forms, 55 scripts and 34 libraries
>>
>> The reason I asked was that a ratio of almost one library per form (335
>> libraries versus 540 forms) suggested you were holding most code in
>> libraries and not sharing it between forms - hence maybe not getting
>> maximum benefit of libraries...
>>
>> Do you have a particular way of handling code that requires lots of
>> libraries?
>
> On forms I do not have almost any code. Only necessary code
> for data-entry (show lookup form, create new document)..
> Everything else is done in libraries: when you enter ID code, I call library
> to
> get its price, I check library to get qty on stock, when you confirm a
> document (for example order or invoice),
> I call library with only ID of that document.
> Usually, for data entry I have les than one library per form.
> Some other libraries are for general analytics in certain module, some are
> for cross module comunication,
> but most of them are for preparing data for reports.

@@@

Understood - makes sense to have as much code as possible in small
number of locations to allow ease of managing business rules about data
entry.

@@@
>
> I have a system with INI files where I can add new analisys methods and
> reports:
> *each form knows from which INI file to read,
> *in INI file I have a group where I list all reports, that are available on
> that form:
> [Reports]
> Form name=report1,report2,report3,analytics1,analytics2,...
> This options are shown on form in popup menu, when I press right mouse on
> printer button.
> I can also set default report for left mouse button.
> So different forms can easily share same reports.
> *when user selects a report, I read from INI file, what to do with that
> choice:
> [Reports]
> Report1=Report,:BMW:rep1,Landscape,1
> ; just show a rsl file
> Report2=Library,:ALIAS:lib,SOME METHOD,:ALIAS:report
> ; open library ":ALIAS:lib" and executemethod "SOME METHOD", which will
> crete answer.db, then show report.
> Report3=Library,:ALIAS:lib,SOME OTHER
> METHOD,:ALIAS:report,Landscape,3,Printer
> ; same as above, only that report is landscape and is printed automaticly in
> 3 copyes.
>
@@@

I have a report table which holds all reports, the methods used to drive
them, and other controls like format and size. Some reports are big
enough to require a plotter and A2 paper. Then I have a form where I can
present the list of reports, complete with information about what they
are for, classified in various ways - for example, Finance, Assets, Work
Management and so on.

I understand the idea of the INI files - but always prefer to use tables
for lists if possible...

@@@
> ALL my libraries have common entry point, which excepts only "method name"
> and var DynArray for parameters.
> ALL my forms have common exit point for calling other objects. In DA they
> store data "who is calling" and
> document ID, I am currenty standing on. That is all I need to do anything
> with that document:
> create a report, copy it, change status, change some data, check for
> stock,...
> So I can create new reports for customers whithiut changing any forms
> (application).
> Just create new library (on separate alias), add choice to INI file and
> create new rsl.
> That is why I have so many libraries, but their average size is 30 kB.
>
@@@

You have about 500 customers (I wish!) but how do you handle the
multiplicity of customers and reports and libraries?

Why not just add a method to a report library (I have 3, for about 250
reports, some of which are really just slight rehashes of some basic
report - same data, different layout)?

On the other hand, the methods do not share much in common, so the main
issue is knowing which library to call.

How do you keep track of which customers have which reports / libraries?

@@@@

> There are also some 20 libraries for commmon use, which handle certain
> actions:
> creating PDFs with different programs, ZIP/unzip, handle INI files,
> translate my installation language scripts,
> create generic lookup forms, ...
>
> I got over size limit for library only in two cases and had to break it up
> to more libraryes.
> I did it in that way, that I still call "maain" library for all methods, but
> for some methods
> in "main" library I just call second library:
> mainlib.lsl:
> method someMethod(var da dynrecord) smallint
> return(mainlib2.someMethod(da))
> endMethod
> So application does not even know, I split up that library.
>
> When I have to call methods in other objects (forms, libs), I explicitly
> define ALL
> methods in USES of that library, NEVER use that short form "uses ObjectPAL
> lib.lsl endUses".
>
@@@

I found using the long form was a pain, in that if you change the
parameters for a method, you have to chase down all the objects that use
the method. Have you found some problem with the short form?

@@@

> And now some things I am very proud of:
> *XML generator I described in some other group,
> *"excel like" parser/calculator with nested ((()())()), iif structure, GOTO
> command, and calls to functions.
> *common method in stock inventory, which accepts only name of answer table
> to fill,
> and then decides (by field name) how to fill appropriate columns. (create
> one giant query with multiple tables,
> links and conditions and also calc structure).
>
> Jure
>
>
 >> Stay informed about: Overview of Paradox database structure and architecture 

> I understand the idea of the INI files - but always prefer to use tables
> for lists if possible...
Hmmm, first programer, that started this application some 15 years ago,
did it with INI files, and since then we got used to it. Can change reports
and
program behavior on site, with notepad, or even over phone.

> You have about 500 customers (I wish!) but how do you handle the
> multiplicity of customers and reports and libraries?
Special customer reports are all stored in a folder with customers name,
there
is usually also a redame file, but in most cases those are just reports with
some logo graphic on it.
> Why not just add a method to a report library (I have 3, for about 250
> reports, some of which are really just slight rehashes of some basic
> report - same data, different layout)?
Because that would be changin my standard application code.
And if I change any of standard objects, I have to distribute this to
all my customers. So I prefer just creating/editing a library in customers
folder
and in this lib I call my standard methods, then maybe do something with
answer
and finally call customers report.

> I found using the long form was a pain, in that if you change the
> parameters for a method, you have to chase down all the objects that use
> the method. Have you found some problem with the short form?
1. You must have all lsl files when you compile an object with short uses
statment.
On my developement setup, I have ALL objects in ?dl files. And if I have to
make changes to any of them, I get ?sl version from our "archive" drive.
So at the end I know exactly which objects I have changed.
2. so when I change parameters of method I am forced to
hunt down all objects that use this method. But usually I do not have to do
this,
because I do not change methods that are used by other objects, I usually
change
just methods that are used inside a form/library.
But when I do change some widely used method (add some funcitonality) I
create
new method with new name and new parameters and change old method so
it calls new method and adds new parameters with blank value.

So if the method is like:
method CutToSize(s string, len smallint) string
if s.size() > len then return(s.SubStr(1,len)) else return(s) endIf
endMethod

and I want to add aligning to right then I would create new method
method CutToSizeAndAllign(s string, len smallint, right true) string
if s.size() > len then s = s.SubStr(1,len) endIf
if right then s=fill(" ",len-s.size())+s
endIf
return(s)
endMethod

and change old method to call new method but still keep its original
behaviour:
method CutToSize(s string, len smallint) string
return(CutToSizeAndAllign(s,len,false))
endMethod
 >> Stay informed about: Overview of Paradox database structure and architecture 

What an application! You are correct to be proud of it.

But when are you going to upgrade it to MS Access?

-Al.

"modri dirkac" wrote:
>> I understand the idea of the INI files - but always prefer to use tables

>> for lists if possible...
>Hmmm, first programer, that started this application some 15 years ago,
>did it with INI files, and since then we got used to it. Can change reports

>and
>program behavior on site, with notepad, or even over phone.
>
>> You have about 500 customers (I wish!) but how do you handle the
>> multiplicity of customers and reports and libraries?
>Special customer reports are all stored in a folder with customers name,

>there
>is usually also a redame file, but in most cases those are just reports
with
>some logo graphic on it.
>> Why not just add a method to a report library (I have 3, for about 250

>> reports, some of which are really just slight rehashes of some basic
>> report - same data, different layout)?
>Because that would be changin my standard application code.
>And if I change any of standard objects, I have to distribute this to
>all my customers. So I prefer just creating/editing a library in customers

>folder
>and in this lib I call my standard methods, then maybe do something with

>answer
>and finally call customers report.
>
>> I found using the long form was a pain, in that if you change the
>> parameters for a method, you have to chase down all the objects that use

>> the method. Have you found some problem with the short form?
>1. You must have all lsl files when you compile an object with short uses

>statment.
>On my developement setup, I have ALL objects in ?dl files. And if I have
to
>make changes to any of them, I get ?sl version from our "archive" drive.
>So at the end I know exactly which objects I have changed.
>2. so when I change parameters of method I am forced to
>hunt down all objects that use this method. But usually I do not have to
do
>this,
>because I do not change methods that are used by other objects, I usually

>change
>just methods that are used inside a form/library.
>But when I do change some widely used method (add some funcitonality) I

>create
>new method with new name and new parameters and change old method so
>it calls new method and adds new parameters with blank value.
>
>So if the method is like:
>method CutToSize(s string, len smallint) string
> if s.size() > len then return(s.SubStr(1,len)) else return(s) endIf
>endMethod
>
>and I want to add aligning to right then I would create new method
>method CutToSizeAndAllign(s string, len smallint, right true) string
> if s.size() > len then s = s.SubStr(1,len) endIf
> if right then s=fill(" ",len-s.size())+s
> endIf
> return(s)
>endMethod
>
>and change old method to call new method but still keep its original
>behaviour:
>method CutToSize(s string, len smallint) string
> return(CutToSizeAndAllign(s,len,false))
>endMethod
>
>
 >> Stay informed about: Overview of Paradox database structure and architecture 

Robert,

Have you looked at ExecMethod()? You can pass a dynarray of data,
including the method name and the library name, to a common method in a
library. This common method then opens the appropriate library, passes
the dynarray of data to that library and calls ExecMethod using the
passed method name. It then returns an answer dynarray containing error
status, error messages and any data or table names to be returned. This
way, any forms only call a single, common method, something like:

HandleMethod(var dynRequest dyAny, var dynResponse dyAny) where dyAny =
dynarray[] anytype.

This has been discussed at length a few years ago (can't remember where)
and is a variation on the "Hercules" example.

Any form, any library, any method to be called. A single (common) method
in the uses clause.

Robert Molyneux wrote:
>
> I found using the long form was a pain, in that if you change the
> parameters for a method, you have to chase down all the objects that use
> the method. Have you found some problem with the short form?
>


--
Tom Krieg

---------------
http://www.krieg.com.au
Please use the contact page to contact me via email
 >> Stay informed about: Overview of Paradox database structure and architecture 

Tom Krieg wrote:
> Robert,
>
> Have you looked at ExecMethod()? You can pass a dynarray of data,
> including the method name and the library name, to a common method in a
> library. This common method then opens the appropriate library, passes
> the dynarray of data to that library and calls ExecMethod using the
> passed method name. It then returns an answer dynarray containing error
> status, error messages and any data or table names to be returned. This
> way, any forms only call a single, common method, something like:
>
> HandleMethod(var dynRequest dyAny, var dynResponse dyAny) where dyAny =
> dynarray[] anytype.
>
> This has been discussed at length a few years ago (can't remember where)
> and is a variation on the "Hercules" example.
>
> Any form, any library, any method to be called. A single (common) method
> in the uses clause.
>
> Robert Molyneux wrote:
>>
>> I found using the long form was a pain, in that if you change the
>> parameters for a method, you have to chase down all the objects that
>> use the method. Have you found some problem with the short form?
>>
>
>
Yes - now use it a lot, but I also have lots of methods that use
specific lists of parameters.

I think the key is to use a dynarray for parameters - so you can add
addition parameters as required without changing the method call,
 >> Stay informed about: Overview of Paradox database structure and architecture 

Exactly.

Robert Molyneux wrote:
>
> I think the key is to use a dynarray for parameters - so you can add
> addition parameters as required without changing the method call,


--
Tom Krieg

---------------
http://www.krieg.com.au
Please use the contact page to contact me via email
 >> Stay informed about: Overview of Paradox database structure and architecture 

"Al Breveleri" je napisal v
sporoèilo ...
>
> What an application! You are correct to be proud of it.
>
> But when are you going to upgrade it to MS Access?
>
> -Al.
>
I was never talking about moving to access (although we are M$ gold
partner).

We have a part of our team working on .NET for 3 years now.
We are still learning and discovering best ways to develop certain type of
application and are writing common parts of application (skeleton):
printing, logging, access, ...

For now we have WBT (Web Based Training) application in .NET,
which is in use with about 20 customers, it is translated to (I think) 13
languages,
and some smaller applications, which were sideproduct of .net learning.

Jure
 >> Stay informed about: Overview of Paradox database structure and architecture 

I was attempting a humorous reference to the post that started this thread.

Note the return email address -- a common phrase meaning, "I have just made
a very bad joke." Note the use of "upgrade" to "Access" -- a snide nod to
what Mr. DiMantova's new client probably believes. Note the <sarcasm>...</sarcasm>
tags --

Aw hell, I left out the <sarcasm>...</sarcasm> tags. The second paragraph
should read, "<sarcasm>But when are you going to upgrade it to MS Access?</sarcasm>".
Sorry.

-Al.

"modri dirkac" wrote:
>"Al Breveleri" je napisal
v
>sporoèilo ...
>>
>> What an application! You are correct to be proud of it.
>>
>> But when are you going to upgrade it to MS Access?
>>
>> -Al.
>>
>I was never talking about moving to access (although we are M$ gold
>partner).
>
>We have a part of our team working on .NET for 3 years now.
>We are still learning and discovering best ways to develop certain type
of
>application and are writing common parts of application (skeleton):
>printing, logging, access, ...
>
>For now we have WBT (Web Based Training) application in .NET,
>which is in use with about 20 customers, it is translated to (I think) 13

>languages,
>and some smaller applications, which were sideproduct of .net learning.
>
>Jure
>
>
 >> Stay informed about: Overview of Paradox database structure and architecture