Paradox Limitations?

Paradox Limitations?

Post by Charles Warde » Thu, 11 Apr 1996 04:00:00

Hi All,

        Can anyone tell me what the limitations are with the Paradox File
Format through the BDE. I will be developing an application that may
have 200 simultanious logins..

As a side note, Client server is not an option at this time.

Any advice or suggestions will be greatly apprecieated.



Paradox Limitations?

Post by JANI JRVIN » Mon, 22 Apr 1996 04:00:00


I minor problem here.. I'm using Delphi 1.0 to access MS Access 1.0
(1.1?) tables via ODBC driver. Now I need to use transactions, but I
cannot get them to work. Imagine the following code:

   With Table1 do Begin
     Table1Field1.AsString := 'ABC';
     Table1Field2.AsInteger := 123;
   With Table2 do Begin
     Table2Field1.AsString := 'XYZ';
     Table2Field2.AsInteger := 987;

When the code gets to the RollBack statement, nothing is actually done!
And of course, that's my problem. I though that the RollBack statement
would roll back the two append's to the two tables, but, well, I guess
I figured wrong.

Has anybody experienced similar behaviour? Is this a bug or feature?

Oh, BTW, it doesn't matter if the last statement would have been
'DataBase1.Commit' - it has no effect either! The data is simply
commited when the Post is called.

Thanks for any info!




Check out Help Editor 2.0 for Windows at:

1996: Only four years to computer confusion!
What have you done to avoid it?
 * SLMR 2.1a *


1. Paradox Form Limitations


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.



2. Valid Method runs twice problem

3. Looking for help on paradox and its limitations

4. Help. Changing current IDENTITY value.

5. Paradox table limitation

6. received SQL1031N during migration

7. Paradox Table Size Limitations ???

8. Windows, dblib, dll, error handler question

9. Paradox Engine Limitations

10. Paradox volume size limitations (DOS and Win95)

11. Paradox engine - limitation of 20 users ??

12. Serious limitations of Paradox for DOS

13. Paradox 9 forms limitations