Dear Support!

We got "table is full" error today.

This table contains WMF files in compressed format.

It have only cca. 25.000 rows. The sysadmin sent us the file sizes, and the EDBBLB size is 8 GB.

What cause this error?
The filesystem is NTFS, as I think it's Win64 machine, and no OS limits on folders or files.

The server's large file support option is 0.

Maybe EDB limits the file sizes?

Thanks

Laszlo Szabo wrote:

> We got "table is full" error today.
>
> This table contains WMF files in compressed format.
>
> It have only cca. 25.000 rows. The sysadmin sent us the file sizes,
> and the EDBBLB size is 8 GB.
>
> What cause this error?
> The filesystem is NTFS, as I think it's Win64 machine, and no OS
> limits on folders or files.
>
> The server's large file support option is 0.
>
> Maybe EDB limits the file sizes?

http://www.elevatesoft.com/manual?action=topics&id=edb2&product=rsdelphi
win64&version=XE2&section=appendix_system_cap indicates no issue.

http://www.elevatesoft.com/manual?action=viewprop&id=edb2&product=rsdelp
hiwin64&version=XE2&comp=TEDBEngine&prop=LargeFileSupport indicates
that the value should be true, and not "0" which you say you have.
That's the first thing to confirm.


--

Matthew Jones

On 1/12/2016 7:28 AM, Matthew Jones wrote:
> http://www.elevatesoft.com/manual?action=topics&id=edb2&product=rsdelphi
> win64&version=XE2&section=appendix_system_cap indicates no issue.
>
> http://www.elevatesoft.com/manual?action=viewprop&id=edb2&product=rsdelp
> hiwin64&version=XE2&comp=TEDBEngine&prop=LargeFileSupport indicates
> that the value should be true, and not "0" which you say you have.
> That's the first thing to confirm.

LargeFileSupport definitely needs to be enabled for this but i thought
the size maxes out at 4GB without it so the 8GB is a curious one.

Raul

Laszlo,

<< The server's large file support option is 0. >>

That setting should be 1 in order to enable large file support.

However, like Raul wrote, I'm not sure why you didn't see this message at the 4GB mark, since that is the file size limit when large file support is not turned on.

Is it possible that you had large file support turned on, but someone accidentally turned it off ?

Tim Young
Elevate Software
www.elevatesoft.com

Dear Tim!

>Tim Young [Elevate Software] wrote:

> That setting should be 1 in order to enable large file support.
> However, like Raul wrote, I'm not sure why you didn't see this message at the 4GB mark,
> since that is the file size limit when large file support is not turned on.
> Is it possible that you had large file support turned on, but someone accidentally turned it off ?

It's interesting. In my machine (Win10 Home) the program stops on 3,9999 GB, and I can't write anymore.

The customer wrote about his system:
2012R2 server, EDB is x64, NTFS

So it's strange.

Thanks!

Laszlo,

<< It's interesting. In my machine (Win10 Home) the program stops on 3,9999 GB, and I can't write anymore.

The customer wrote about his system:
2012R2 server, EDB is x64, NTFS >>

Do you ever ship any EDB Servers with large file support enabled ?   Can the customer change the EDB Server settings, or do they know how to do so ?

Tim Young
Elevate Software
www.elevatesoft.com

On 1/13/2016 5:42 AM, Laszlo Szabo wrote:
> It's interesting. In my machine (Win10 Home) the program stops on 3,9999 GB, and I can't write anymore.

This is not an OS limitation - you DO NOT have LargeFileSupport enabled
in EDB engine or EDBSrvr (if C/S).

Quick test on my machine (Win 8.1 pro, 64bit) shows following when
populating a single table.:

A. LargeFileSupport = False

When table gets to "3.72 GB (3,999,997,952 bytes on disk)" i receive
"ElevateDB Error #407 The table testtable is full" error and cannot add
any more data.

B. LargeFileSupport = True

Other than LargeFileSupport setting the application is exactly the same
as in test A.

I stopped the test once the table reached 11.3 GB (12,181,630,976 bytes
on disk) simply because i did not want to wait.

EDB official limit is 128,000,000,000 bytes which i believe is around
119 GB and i have no doubt it would have kept growing to this size.


Raul

>Tim Young [Elevate Software] wrote:
>
>Laszlo,
>
><< It's interesting. In my machine (Win10 Home) the program stops on 3,9999 GB, and I can't write anymore.
>
>The customer wrote about his system:
>2012R2 server, EDB is x64, NTFS >>
>
>Do you ever ship any EDB Servers with large file support enabled ?   Can the customer change the EDB Server >settings, or do they know how to do so ?

Dear Tim!

It's very interesting. We never used Large File Support on servers/clients.

Yesterday we found a server (Win7-64bit I think) where the "printing_log" table is 12,999 GB and from this point they got error.
They could exhaust the 8 GB limit with this size...!

I tried to optimize it, but I got #407 error at the 15-20% of the process.

It's very interesting, cos it seems to be different than normal.

Once it can grow bigger than 4 GB limit, but never again?

We had only one speciality: many of the tables we upgraded from DBISAM, and we used 2.11b3 for long period.

Laszlo,

<< Yesterday we found a server (Win7-64bit I think) where the "printing_log" table is 12,999 GB and from this point they got error.  They could exhaust the 8 GB limit with this size...!

I tried to optimize it, but I got #407 error at the 15-20% of the process.

It's very interesting, cos it seems to be different than normal.

Once it can grow bigger than 4 GB limit, but never again? >>

No.  Something, or somebody, somewhere turned *on* large file support in ElevateDB and updated the table. That's the only way to add that much data to an existing table over and above 4GB.

Tim Young
Elevate Software
www.elevatesoft.com

>Tim Young [Elevate Software] wrote:
>
>No.  Something, or somebody, somewhere turned *on* large file support in ElevateDB and updated the table. That's > the only way to add that much data to an existing table over and above 4GB.
>
>Tim Young
>Elevate Software
>www.elevatesoft.com

Dear Tim!

We checked this. We can't optimize this table. We tried to create same table and insert, but the process also failed.
Same error, same problem - the new table is limited to 4 GB.

I have two ideas.

1.)
We migrated this table from DBISAM. Maybe this process can exhaust the limits?

2.)
Formerly we used 2.11 DEBUG versions. They may read the Large File Support options as True (as default), and this caused big files?

I have no other idea about it.

Thanks