Ever thought of building/administering a Network hosted, 1 Terabyte/5 Billion Row, relational MS-Access database, that does not require MS-Access software or licensing, for your multi-user department at work to use?

Actually, MS-Access software is not used, just the underlying Jet (Red) Engine for MS-Access which comes factory installed on Windows 7 O/S Home Premium, along with the ODBC Administrator utility which can be used to create empty *.MDB files in the latest Jet 4.x format, with capacity of 2 GIG, and allowing for data encryption and compression. I use Jetcomp40.exe to optimize/compact/repair/reorganize the database periodically. This utility runs in batch mode. Takes 5 minutes to run on a single 10 million row MDB file, and that is on a very modest laptop with a single processor, 3 GIG RAM, 2.2 GHz. No telling what it would take on a dedicated and robust Windows Server. One thing to keep in mind is that it has been said that 99.99% of MDB corruption issues in the past have been attributed to MS-Access software front-end in combination with putting all the DB OBJECTS (Tables, Queries, Macros, Forms, Reports,etc.) within the same MDB file. I only use TABLE Objects with the associated indexes. Using ODBC, this makes for a very stable DB environment. Server Hardware makes a big difference, and it is recommended to us a LAN instead of a WLAN or WAN.

I use Perl code to create the Tables and Indexes (or Constraints) within an empty MDB file. Once built, that single MDB file can be copied hundreds of times to other MDB files with different names for use in your database. This database is made up of a 100's of MDB files acting as a partial/common table across all MDB files. This allows you to build a huge table with billions of rows. The MDB files are not linked nor split. The data is logically segregated so that your PERL application can open an ODBC connection to the appropriate MDB file to perform random access. I use file naming convention to determine which MDB file to access. Example: US_CENSUS_2010_TX_A.mdb would contain the data for citizens living in Texas whose last name begins with "A". Whatever works for your business.

Two(2) years ago I started a topic of conversation on this at SQL SERVER CENTRAL that infuriated a few folks, and made everyone dig into this topic of conversation. I purposely made it sound like it was a downsize to move from SQL Server to Jet Engine.

SEE: https://www.sqlservercentral.com/Forums/1717865/MS-Jet-Engine-4x-ODBC-enabled-databases-to-1-Terabyte5-billion-rows-or-SQL-SERVER?PageIndex=1

Also see the "Microsoft Jet Engine Database" page at Wikipedia, which I contributed to (most of the opening section before the section on Architechture).

SEE: Microsoft Jet Database Engine

You can also find this topic discussed at Microsoft. SEE: https://social.msdn.microsoft.com/Forums/office/en-US/d768ffb9-08ad-4998-a71d-04b869c13ca8/ms-jet-red-database-engine-4x-capacity-testing-is-mssql-server-even-necessary?forum=accessdev

I am calling it Reduction Database Technology since it takes MS-Access software out of the picture, thus releasing Jet Engine to perform to its fullest potential.

I personally use the Win32 Perl development language (ActiveState, ActivePerl - 5.6.1, binary build 638) which comes with David Roth's very stable Win32::ODBC module, which I have used since 1998 without a hitch. I also use the IndigoSTAR PL to EXE compiler for standalone and freely distributable Perl application programs, which also works flawlessly. I employ Transaction Processing with ODBC, so that "all or none" of my SQL maintenance requests are applied using COMMIT or ROLLBACK. I use the Win32:GUI module to create the front-end DB user-interface.

If anyone wishes me to post some code examples here let me know. You can find samples at my post at SQL SERVER CENTRAL on the last page of the discussion (page 25).