BDE 5.1x and dBase Tables
John J. Bowman
experienced these problems as I have, but here goes...
Problem 1 (and the most urgent one):
I have a program written in Delphi 5 (Update Pack 1) and BDE 5.11 under
Windows NT4 SP5. In one procedure, I attempt to make a copy of a 200MB
dBase table using the Batchmove command. I've pasted a piece of the code
below. As you can see by the comments, I've tried this two different ways.
It seems that if the components exist on the main form, the batchmove is
successful; however, if the components exist in a Datamodule, the process
fails. Now, prior to this procedure, a similar procedure is called
involving a 5MB dBase table. That procedre looks exactly like the one below
except tblMPRS is replaced with tblFacEdt. That procedure executes
properly.
The error I get is "Insufficient Disk Space". In the BDE Configuration
utility, the default dBase settings are for level 5 with block sizes of
1024. The LANGDRIVER is set to 'ascii' ANSI. I have attempted this with
BDE 5.11 as well as BDE 5.10 (which ships with Delphi 5). The TEMP and TMP
directory are both set to F:\TEMP, which has 1.23GB free space. The C:
drive contains 640MB free space. And, the destination drive contains 4.3GB
free space.
I also have a TSession component in the Datamodule whose AutoSessionName is
set to TRUE. All components of the DataModule is set to this Session. The
reason for this is so I could define the PrivateDir upon the main form's
FormShow event. However, I have tried this both with, and without, the
TSession component and it still fails.
Finally, as further confusion... this process works properly on my machine
in the office; however it does not work on my machine at home. Below are
the machine breakdowns:
Code:
---------
procedure TDataModule2.BackupMPRS(Src, SystemDir : string);
begin
// Set Source File. Use a Query component so Batchmove won't copy Src's
indexes
qrySrc.SQL.Clear;
qrySrc.SQL.Add(Format('select * from "%s"',[Src]));
// Set Destination Table properties
tblMPRS.DatabaseName := SystemDir;
tblMPRS.TableName := ExtractFileName(Src);
tblMPRS.TableType := ttdBase;
// Try calling Batchmove method instead of Batchmove component. Perhaps
successful?
tblMPRS.BatchMove(qrySrc,batCopy);
// Set BatchMove properties and execute copy
{ bmCopy.Source := qrySrc;
bmCopy.Destination := tblMPRS;
bmCopy.Mode := batCopy;
bmCopy.Execute; }
end;
Machine in the Office:
------------------------------
Dual Coppermine 600Mhz
512MB RAM
2 - 18.2GB SCSI-2 Drives
Matrox Millenium G400 Video
Windows NT 4.0 Workstation SP5
512MB Swap
BDE 5.11 (installed as a runtime BDE)
Machine at Home:
-------------------------
Pentium III 450Mhz
128MB RAM
1 - 13.2GB UATA/66 Drive
1 - 20.1GB UATA/66 Drive
ATI XPert 98 Video
Windows NT 4.0 Workstation SP5
512MB Swap
BDE 5.10 (installed with Delphi 5) (I've also tried upgrading to 5.11
without success)
Problem 2:
---------------
I have a program originally written in Delphi 3.0 (no update packs) and BDE
4.51. It uses Seagate Crystal Reports component to do reporting. The
Delphi application does some rudimentary data manipulation and lookups and
saves to a temporary dBase answer table (level 5), which is then passed to
Crystal Reports. This temporary dBase table is created programatically
using the TTable.CreateTable method.
When the application is run on any WinNT machine containing BDE 4.51, the
queries perform successfully and the report in Crystal Reports is generated
without a problem. When the application is moved to a WinNT machine
containing BDE 5.10 or higher, the queries are performed successfully;
however, the reports are always generated with no data. Crystal Reports
sees the dBase table as having 0 records. Nothing programmatically has
changed. None of the source files, from which the data is drawn, change
between machines. All data is being pulled locally and not across a
network.
DBD reports the temporary "answer" table as being dBase level IV. I've
checked on Seagate Software's website as well as community.borland.com. I
can find nothing on either of these problems. Does anyone else know of any
incompatibilities with BDE 5.1x or higher? Anyone know of any updates or
fixes?
These problems have been easily reproducable in different applications and
on different machines with different platforms. The only common thread I'm
noticing between everything I've tried is the BDE version. Can anyone offer
any solutions or work-arounds?
Thanks!
-John Bowman
jbo...@hpis.net
P.S. I apologize for the insanely long message; however I believe it best
to be a thorough as possible when asking help to solve a problem.
Brian Bushay TeamB
>I also have a TSession component in the Datamodule whose AutoSessionName is
>set to TRUE. All components of the DataModule is set to this Session. The
>reason for this is so I could define the PrivateDir upon the main form's
>FormShow event. However, I have tried this both with, and without, the
>TSession component and it still fails.
You don't need a session component to set a privateDir. When BDE starts it
creates a default session. You need to make sure you session.privateDir gets
set before any datasets are opened so you also need to make sure they all get
closed in the IDE.
My guess is there are some components you don't have set to your session
component or the tables attached to it get opened before you set the PrivateDir
location.
--
Brian Bushay (TeamB)
Bbu...@NMPLS.com
John J. Bowman
>
>You don't need a session component to set a privateDir. When BDE starts it
>creates a default session. You need to make sure you session.privateDir
gets
>set before any datasets are opened so you also need to make sure they all
get
>closed in the IDE.
>My guess is there are some components you don't have set to your session
>component or the tables attached to it get opened before you set the
PrivateDir
>location.
>
>
>--
>Brian Bushay (TeamB)
>Bbu...@NMPLS.com
Brian,
I thought about that; however, all components, except for bmCopy
(TBatchmove) are set to the TSession component. The TSession component is
opened before any of the procedures are called. This is the first step I
perform inside a try...finally block. In the "finally" portion, the
TSession component is closed again. Thanks for bringing up the global
Session variable, though. I had forgotten that I don't need to create a
separate TSession component just to set the PrivateDir. I'll make that
change.
I also did further testing of the application in "Problem 1" and I believe I
may have narrowed it down a bit. First, I attempted to make a copy of the
dBase table into a Paradox table using DBD's Table --> Utilities --> Copy
command. That performed successfully. Then I modified the procedure as
follows and passed the new Paradox table as the Src variable:
procedure TDataModule2.BackupMPRS(Src, SystemDir : string);
begin
// Set Source File. Use a Query component so Batchmove won't copy Src's
indexes
qrySrc.SQL.Clear;
qrySrc.SQL.Add(Format('select * from "%s"',[Src]));
// Set Destination Table properties
tblMPRS.DatabaseName := SystemDir;
//tblMPRS.TableName := ExtractFileName(Src);
//tblMPRS.TableType := ttdBase;
tblMPRS.TableName := 'MPRS_2';
tblMPRS.TableType := ttParadox;
tblMPRS.BatchMove(qrySrc,batCopy);
end;
I found that doing a batchmove from a Paradox table to a Paradox table also
fails. Next, thinking possibly it might be a bad installation of Delphi 5,
I completely uninstalled Delphi 5 and the BDE directory, reinstalled Delphi
5, added the D5 Update patch, and left the BDE at 5.10. Then, I recompiled
the application and tried again. Again, no luck.
Finally, I copied the application and data onto another machine (specs
below) with BDE 5.11 runtime and ran the application. As with the SCSI
machine at the office, this time it worked. So, I ran it three more times.
Every time, it worked. What I'm *guessing* is that the DbiBatchmove method
of BDE 5.1x was rewritten since 4.51, possibly using lower-level hard-drive
access code (perhaps to optimize the moving of the data)??? This code seems
to work successfully on SCSI and regular IDE drives; however, there's a
glitch somewhere when an Ultra-ATA/66 controller is used? I'm arriving at
this since the program only seems to crash on machines using Ultra-ATA/66
drives connected to Ultra-ATA/66 controllers. I don't believe this to be a
controller problem since the same code compiled under Delphi 3 with BDE 4.51
runs without a problem on this machine.
Here's the machine specs again for the UATA machine at home (the one that
fails):
Pentium III 450
ABIT BE6 Motherboard (built-in IDE and UATA controller)
BIOS Rev PL (latest)
UATA BIOS Rev 1.21 (latest)
128 MB RAM
1 - 13.2GB UATA drive (on UATA controller)
1 - 20.1GB UATA drive (on UATA controller)
ATI XPert 98 8MB AGP Video
768MB - 1024MB Swap File
Here's the machine specs for the test machine at home (which worked):
Dual Celeron 433
ABIT BP6 Motherboard (built-in IDE and UATA controller)
BIOS Rev NJ (2nd to latest. Latest simply fixes problem with Win2000)
UATA BIOS Rev 1.21 (latest -- same BIOS/controller as BE6 above)
96 MB RAM
1 - 20.1GB UATA drive (on IDE controller)
1 - 10.2GB UATA drive (on IDE controller)
3Dfx Velocity 100 8MB AGP Video
768MB - 1024MB Swap File
Any ideas?
Thanks.
-John
Brian Bushay TeamB
>What I'm *guessing* is that the DbiBatchmove method
>of BDE 5.1x was rewritten since 4.51, possibly using lower-level hard-drive
>access code (perhaps to optimize the moving of the data)??? This code seems
>to work successfully on SCSI and regular IDE drives; however, there's a
>glitch somewhere when an Ultra-ATA/66 controller is used? I'm arriving at
>this since the program only seems to crash on machines using Ultra-ATA/66
>drives connected to Ultra-ATA/66 controllers. I don't believe this to be a
>controller problem since the same code compiled under Delphi 3 with BDE 4.51
>runs without a problem on this machine.
I do not remember anyone else reporting similar problems. I have heard that
there where a fair number of the early Ultra-ATA drivers that fail when the data
transfer rate gets high.
Jan Sprengers
<jbo...@hpis.net> wrote:
>Problem 1 (and the most urgent one):
>
>I have a program written in Delphi 5 (Update Pack 1) and BDE 5.11 under
>Windows NT4 SP5. In one procedure, I attempt to make a copy of a 200MB
>dBase table using the Batchmove command. I've pasted a piece of the code
>below. As you can see by the comments, I've tried this two different ways.
The last two years, there have been about 4 reports here of BatchMove
failing on large dBase tables. I'm not entirely sure that your
problem is in the same category though. IIRC, most messages talked
about a read/write error message.
AFAIK, there has never been a clear cause for this.
>It seems that if the components exist on the main form, the batchmove is
>successful; however, if the components exist in a Datamodule, the process
>fails.
That's pretty weird. How could the location of the component
influence the BDE's behavior?
>Finally, as further confusion... this process works properly on my machine
>in the office; however it does not work on my machine at home. Below are
>the machine breakdowns:
Check out the BDE settings. Default table level, language driver,
etc. Perhaps this is related to the problem. I would be very
surprised to see that hardware is important here.
As a workaround, you can use DbiMakePermanent to make a copy of your
SQL result table. This will probably be a bit faster than batchmove
as well.
>Problem 2:
>---------------
>
>I have a program originally written in Delphi 3.0 (no update packs) and BDE
>4.51. It uses Seagate Crystal Reports component to do reporting. The
>Delphi application does some rudimentary data manipulation and lookups and
>saves to a temporary dBase answer table (level 5), which is then passed to
>Crystal Reports. This temporary dBase table is created programatically
>using the TTable.CreateTable method.
>
>When the application is run on any WinNT machine containing BDE 4.51, the
>queries perform successfully and the report in Crystal Reports is generated
>without a problem. When the application is moved to a WinNT machine
>containing BDE 5.10 or higher, the queries are performed successfully;
>however, the reports are always generated with no data. Crystal Reports
>sees the dBase table as having 0 records. Nothing programmatically has
>changed. None of the source files, from which the data is drawn, change
>between machines. All data is being pulled locally and not across a
>network.
Sounds to me like the default table level isn't the same on both
machines and that Crystal Report isn't able to deal with the dBase
table version that you're creating on the problematic machine. Check
out the default table level and eventually show us the code you use
for creating the temp table.
Jan
Colin Acheson
batch copy traverse the network?
I noticed an interesting problem recently on my NT4 / Win98 network.
When I had the TCP/IP settings for the network cards set to "Obtain an
IP address automatically", there were errors when I tried to copy very
large files across the network, even using explorer. I can't remember
what the error message was but the copy frequently failed. The
problem was eliminated when I "hard-wired" the IP addresses by
selecting "Specify an IP address".
It is only a guess but I suspect that Windows may periodically change
the IP addesses (as a security measure) when set to auto., thus
interrupting long tasks. I now use NetBEUI as well as TCP/IP.
Regards,
Colin Acheson
On Sun, 28 May 2000 16:47:10 -0400, "John J. Bowman"
<jbo...@hpis.net> wrote:
<details snipped>