Paradox 9 forms limitations

Paradox 9 forms limitations

Post by newsgroup » Sat, 14 Sep 2002 17:13:38



I'm designing a form that needs to have a lot of stuff in it.  I may
need to include about 10 tables with about 70 fields each, and I don't
know yet how much opal code.  Before I actually do this I would like
to get an idea if I would be running into any limitations with Paradox
9 forms.. either practical limitations or actual program capacities.
I know this question may sound overly general, but I was wondering if
anyone has had any experience with putting so much stuff on one form
that it either didn't run, or it got real sluggish.  Right now I'm
just looking for some general guidelines to help me figure out if I
need to reconsider my design.  Or if someone knows where I could find
a good discussion of this that would be really helpful.  Thanks.
 
 
 

Paradox 9 forms limitations

Post by Liz » Sat, 14 Sep 2002 23:20:56


Newsgroupie?,

Unless you've got the fastest hardware, the most stable version
of Windows (ha ha) and the fastest network (or are using local
files) under the sun; or unless those tables only have a handful
of records each, that's gonna be one slow form.  And it might be
slow anyway, depending on the amount of data, how the tables are
related and what you do on the form.

That said, you won't be violating any documented software
limitations that I know of.

However, I would strongly recommend multiple forms.  I would also
recommend serious examination of those 70-field tables to see if
some normalization isn't needed.

Without knowing more, I can't recommend anything other than
re-examining the need.

It shouldn't take that long to throw together a quick form with
just the tables and the uiobjects (no need to make it pretty
yet), save and deliver it and then see how long it takes to
open...

Liz


> I'm designing a form that needs to have a lot of stuff in it.  I may
> need to include about 10 tables with about 70 fields each, and I don't
> know yet how much opal code.  Before I actually do this I would like
> to get an idea if I would be running into any limitations with Paradox
> 9 forms.. either practical limitations or actual program capacities.
> I know this question may sound overly general, but I was wondering if
> anyone has had any experience with putting so much stuff on one form
> that it either didn't run, or it got real sluggish.  Right now I'm
> just looking for some general guidelines to help me figure out if I
> need to reconsider my design.  Or if someone knows where I could find
> a good discussion of this that would be really helpful.  Thanks.


 
 
 

Paradox 9 forms limitations

Post by Dennis Santor » Sat, 14 Sep 2002 23:51:31


I've built forms with around 30 tables and compiled size near half a meg.
I don't generally recommend it but it can be done when needed. There are
some limitations to proc size. Best to generally avoid them. And you can
and should move as much code as possible out to libraries. Try not to
embed any dll/s or ocx's in a large form as it will increase the
complexity and potential problems.

Also, check out my paper on Containership on forms to get some sense of
ways to lay things out (no bare fields, using notetabs, MROs etc.) so you
can save some problems there. The paper is available on our Paradox
resources page (link in my signature) along with many other useful things.
I suggest the papers on Database Basics and on Normalization if you have
not read them yet either.
HTH

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


> I'm designing a form that needs to have a lot of stuff in it.  I may
> need to include about 10 tables with about 70 fields each, and I don't
> know yet how much opal code.  Before I actually do this I would like
> to get an idea if I would be running into any limitations with Paradox
> 9 forms.. either practical limitations or actual program capacities.
> I know this question may sound overly general, but I was wondering if
> anyone has had any experience with putting so much stuff on one form
> that it either didn't run, or it got real sluggish.  Right now I'm
> just looking for some general guidelines to help me figure out if I
> need to reconsider my design.  Or if someone knows where I could find
> a good discussion of this that would be really helpful.  Thanks.

 
 
 

Paradox 9 forms limitations

Post by newsgroup » Sun, 22 Sep 2002 12:40:32


Thanks Liz and Dennis for your replies.  I've read some of the
articles on your website, and they were a lot of help... particularly
the one on containership.  Since I originally posted my question I've
been reconsidering the overall design of my project, and decided on a
different approach requiring a lot less stuff on one form.  A complete
restructuring/normalization of the existing data is not an option
right now, but occassionally I'm able to make changes to move things
in that direction.  Thanks again for your help.
 
 
 

Paradox 9 forms limitations

Post by Dennis Santor » Sun, 22 Sep 2002 23:22:37


Glad you found some of the info helpful. Good luck on your project and ask
when questions come up.

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


> Thanks Liz and Dennis for your replies.  I've read some of the
> articles on your website, and they were a lot of help... particularly
> the one on containership.  Since I originally posted my question I've
> been reconsidering the overall design of my project, and decided on a
> different approach requiring a lot less stuff on one form.  A complete
> restructuring/normalization of the existing data is not an option
> right now, but occassionally I'm able to make changes to move things
> in that direction.  Thanks again for your help.

 
 
 

Paradox 9 forms limitations

Post by Kennet » Mon, 23 Sep 2002 05:55:11




Quote:> A complete
>restructuring/normalization of the existing data is not an option
>right now, but occassionally I'm able to make changes to move things
>in that direction.

Howdy,

Few know less about all this than I, but...

With the comment above you might be choosing many small hassles rather
than one small hassle.

Normalizing now is not likely to be much of a problem in practice, but
it will pay enormous rewards down the road.

Whatever you decide, best of luck with the project,
--
Kenneth

If you email... Please remove the "SPAMLESS."

 
 
 

1. Paradox Form Limitations

Hi,

Do any of you know whether Paradox 10 forms have the capacity to host more
objects than Paradox 7_32 forms?

I support a stable application built 5 years ago using a combination of
Paradox7_32, Delphi 3, and C++.  It is a tool for manual recording of
complex geological data using ruggedised pen tablet computers.  The main
data entry screen is a Paradox form hosting several toolbars, a multipage
notebook containing several hundred data-producing objects (buttons, fields,
table frame arrays, etc) and a C++ graphical workspace that allows the user
to draw an object and attach property-value data trees to that object using
objects on various pages of the notebook.  The system contains many dialogue
boxes triggered by specific user input on the main form, but the users hate
these because they interrupt an otherwise smooth workflow, and slow
productivity significantly.  These guys work long hours standing outdoors
year-round in temperatures ranging from freezing to 45 degrees Celsius, so
they want the interface as flat as possible to enable them to get the data
into the machine faster.  They'd prefer to flatten ALL the functionality
onto one monster form.  Consequently, the object count on the main form has
grown progressively and almost all ObjectPAL code has been placed in
libraries.  Unfortunately, if we add any more objects to the main form it
becomes unstable (does crazy things in design mode and won't compile).  So,
I'd be very grateful to learn whether any of the long-term Paradox
developers among you have bumped into this kind of problem before and know
whether Paradox 10 forms have greater capacity than Paradox 7 forms (not the
sort of info one can find in a 'features' list).  Replacing the Paradox
forms with Delphi equivalents is probably the answer, but that's a major
development task.  I'm just trying to find ways of streamlining the workflow
without rebuilding an otherwise satisfactory system.

Thanks,

Ken

2. acc97: problem with sorting data

3. paradox->html?? html form->paradox

4. variable and cusor definition

5. Possible convert crystal report forms to paradox forms????

6. Row Locking

7. Loading a paradox form without paradox program

8. Append memo prob w/ FP2.0 SDK

9. Form Text Limitation Using Web Companion

10. Paradox table limitation

11. Paradox Limitations?

12. Looking for help on paradox and its limitations

13. Help with Paradox Space Limitation