September 14, 2015 at 11:02 am
Matt Miller (#4) (9/14/2015)
where the savings justify the pain and cost you're putting your user base through.
We are surrounded by "cheap" here (UK side). Maybe different where you are?
Big discounts to become a new customer for a Utility, Insurance company, Credit Card, Bank ...
Absolutely no discount for being a long standing loyal customer. YOU they will fleece. They will not tell you there is a cheaper deal you can ask for. If you are paying off an "including handset" phone contract they won't reduce the price when you have finished paying for the handset ... unless you know to ask. Everywhere you park the parking price will be relatively low, but they will try to fine you instead.
I fail to understand the business model that prefers the cost of acquiring new customers to keeping existing ones. Someone told me that the Utility Companies make plenty of money from selling the demographic data of their mailing list ... so customers only staying a year made them more money from having more new customers. Seems daft to me ... but ...
Its bred a thought process of "low price is better than good quality".
I suspect it will come full-circle.
September 14, 2015 at 11:15 am
Kristen-173977 (9/14/2015)
Matt Miller (#4) (9/14/2015)
where the savings justify the pain and cost you're putting your user base through.We are surrounded by "cheap" here (UK side). Maybe different where you are?
Big discounts to become a new customer for a Utility, Insurance company, Credit Card, Bank ...
Absolutely no discount for being a long standing loyal customer. YOU they will fleece. They will not tell you there is a cheaper deal you can ask for. If you are paying off an "including handset" phone contract they won't reduce the price when you have finished paying for the handset ... unless you know to ask. Everywhere you park the parking price will be relatively low, but they will try to fine you instead.
I fail to understand the business model that prefers the cost of acquiring new customers to keeping existing ones. Someone told me that the Utility Companies make plenty of money from selling the demographic data of their mailing list ... so customers only staying a year made them more money from having more new customers. Seems daft to me ... but ...
Its bred a thought process of "low price is better than good quality".
I suspect it will come full-circle.
Just to be clear - I was still talking about Eric's premise (build your own DBMS). Choosing between multiple options of DBMS, yes - lots of different ways to go to include some of the open source.
Finding the cheapest option is everyone's challenge these days: I just don't automatically buy into the "no yearly license = cheaper" mantra. Just look at those "Free TO Play" games that keep popping up by the hundreds, and you'll see that a subscription model is often many increments cheaper than the "death by microtransaction" model.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
September 14, 2015 at 1:01 pm
Matt Miller (#4) (9/14/2015)
Just to be clear - I was still talking about Eric's premise (build your own DBMS).
I was picking up on your point about the pain that it put users through (that the core database functions are homegrown rather than the, perhaps more expensive, initially, "tried and tests on tens-of-thousands of projects" ... and my ranting on my Hobby Horse that users seem to want Cheap rather than Reliable / Robust, and how little weight users attach to the amount of time they might waste installing, debugging, and from the ensuing hassle that poor performance and poor build quality brings with it.
In going-off-on-one! I was pretty cryptic as to what I was referring to, sorry about that.
September 14, 2015 at 1:12 pm
erichansen1836 (9/12/2015)
One big complaint I would have in parting is that the users need to have physical access to the DB stores. Sure you can play games and obfuscate, etc.... but the fact is - they have physical access to all of the data AND the DB files AND the lock files, and by the way - they happen to have rights to modifying the content and the files too. To me that's the kiss of death (and I was on the receiving end of this): A user sees the content, and wants to work .ate, so they "drag" a copy of this onto their laptop before heading home, etc.... they didn't copy, they moved it, and now the file's not where it needs to be. All of your data just left the building, and you're left HOPING that was a happy accident and not someone pissed off at the organization.
My plan is to get with the System Admin person and setup a directory structure on the Network hosting the *.MDB file system, so that:
(1) The *.MDB files can be made invisible
(2) The directories can have group permission to prevent COPY, DELETE, MOVE of *.MDB files and lock files, etc.
(3) The Win32 Perl/ODBC user interface would accept login credentials from each user, and if authorized, the user would be logged into the Menu System of the Database Interface. Each user has their login credentials stored in an ADMIN table (*.MDB) file for that purpose. It also tells the ACCESS LEVEL they have to Maintenance Programs (Menu Options).
(4) When a user is successfully logged in to the database user interface software, that user is then logged in (by this database user-interface) as a database user with group permissions to the Network Database directory structure and files. Users cannot access the Database directory structure on the Network to screw around with the files or data they contain, but only have indirect and controlled access to these files through the database user-interface - which dynamically builds the syntactically correct SQL statements to process and limits the number of Result Set rows returned.
Speaking of costs driving decisions, what factors weight into deciding against Postgresql? If you're already slinging perl, I would have thought Postgresql would have been a natural choice here. Did you evaluate it to any degree?
September 14, 2015 at 2:01 pm
The OP seems to be looking for justification of his personal decisions regarding architecture.
Sure, stick with this system. It will work. Will anyone else be able to help support it?
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
September 14, 2015 at 2:10 pm
Kristen-173977 (9/14/2015)
Matt Miller (#4) (9/14/2015)
Just to be clear - I was still talking about Eric's premise (build your own DBMS).I was picking up on your point about the pain that it put users through (that the core database functions are homegrown rather than the, perhaps more expensive, initially, "tried and tests on tens-of-thousands of projects" ... and my ranting on my Hobby Horse that users seem to want Cheap rather than Reliable / Robust, and how little weight users attach to the amount of time they might waste installing, debugging, and from the ensuing hassle that poor performance and poor build quality brings with it.
In going-off-on-one! I was pretty cryptic as to what I was referring to, sorry about that.
No issue - just making sure we were still talking apples to apples!
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
September 14, 2015 at 2:22 pm
erichansen1836 (9/12/2015)
One big complaint I would have in parting is that the users need to have physical access to the DB stores. Sure you can play games and obfuscate, etc.... but the fact is - they have physical access to all of the data AND the DB files AND the lock files, and by the way - they happen to have rights to modifying the content and the files too. To me that's the kiss of death (and I was on the receiving end of this): A user sees the content, and wants to work .ate, so they "drag" a copy of this onto their laptop before heading home, etc.... they didn't copy, they moved it, and now the file's not where it needs to be. All of your data just left the building, and you're left HOPING that was a happy accident and not someone pissed off at the organization.
My plan is to get with the System Admin person and setup a directory structure on the Network hosting the *.MDB file system, so that:
(1) The *.MDB files can be made invisible
(2) The directories can have group permission to prevent COPY, DELETE, MOVE of *.MDB files and lock files, etc.
(3) The Win32 Perl/ODBC user interface would accept login credentials from each user, and if authorized, the user would be logged into the Menu System of the Database Interface. Each user has their login credentials stored in an ADMIN table (*.MDB) file for that purpose. It also tells the ACCESS LEVEL they have to Maintenance Programs (Menu Options).
(4) When a user is successfully logged in to the database user interface software, that user is then logged in (by this database user-interface) as a database user with group permissions to the Network Database directory structure and files. Users cannot access the Database directory structure on the Network to screw around with the files or data they contain, but only have indirect and controlled access to these files through the database user-interface - which dynamically builds the syntactically correct SQL statements to process and limits the number of Result Set rows returned.
You can obfuscate (i.e. make it hard for the user to know where to go to find the files), but you can't completely remove permissions. I know - I did it for years in an app of my own. I also know it was a bit of a parlor trick that would fall apart if any of your users are at all inclined to push the limits and start poking around.
For one thing you need DELETE access of locked files, unless you plan to outfit JET with a brand new locking mechanism (lock files are deleted when the last user logs out of the app for the day). You also need to have read/write access, or you won't be able to update content. (4) is a non-starter as well, without going to some fairly extreme measures to somehow confer application level security that's distinct from the network access you're currently using. So you have the access level defined somewhere - how do you secure THAT .MDB to prevent someone from tampering? etc.
Look - I am not trying to dissuade you. You've obviously embarked on a path you plan to see through. I just feel you're about to take on a rather extreme amount of effort someone else has already thought through and tested to a degree you simply won't be able to match with a custom piece of code.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
September 15, 2015 at 9:49 am
WHEN TO USE:
SQL SERVER
========
* For Network or non-Network Databases larger than 5 Terabytes and 25 Billion rows - use SQL Server
* For Network Databases smaller than 5 Terabytes and 25 Billion rows, but with heavy client-side concurrent
maintenance and query requests being performed (or potentially performed) by 100s or 1000s of users
- use SQL Server
* For Read/Write Databases used over a WAN (wide area network) - use SQL Server.
* For Corporations where Network Databases are in the 10s of Gigabytes (or more), and money is no object
for hiring highly trained SQL Server Admins and purchasing SQL Server products and licensing for the
entire Enterprise - use SQL Server.
JET ENGINE
========
* For Database situations NOT listed above (i.e. for SQL SERVER) - use Jet Engine (FREE/NO COST)
MICROSOFT RECOMMENDS: https://support.microsoft.com/en-us/kb/303528
from ARTICLE: How to keep a Jet 4.0 database in top working condition
Use a robust file server
==============
Make sure that you have a robust file server that can handle the number of users and the requests that are being made to the Microsoft Jet database file. Additionally, make sure that the file server is not overtaxed with handling other processes, such as acting as a Windows domain controller, an Exchange server, or a SQL Server.
A problem also occurs if you restart the server to fix a problem with another important service, such as the mail service. Problems also occur when you restart the server after you apply new software or you apply a service pack or a hotfix, and you forget that the Microsoft Jet database is currently shared on the server. When the file server is restarted, unexpected interruption of the client connections to the database occur. This may cause database corruption. To prevent interrupted client connection, all clients must close the database before the file server is restarted or before software updates to the file server are applied.
A file server must also be put in a secured location where the file server cannot be accidentally switched off. The server must have an uninterrupted power supply (UPS) to help protect from intermittent power outages or from power fluctuations. The network file server must also have the following:
High-performance hard drives
A high-quality network card
Lots of RAM to make sure that the server can handle the load
Verify network connectivity
===========================
Make sure that you have a stable network and a fast network with stable network connectivity to the network file server. We recommend that you do not use Microsoft Jet over a WAN, over a modem connection, or over FTP, or any other less-than-reliable network transport. Because Microsoft Jet is a file-sharing database system, any less-than-reliable network transport increases the chances of a dropped client. This can increase the chance of database corruption.
Minimize the number of connections that are made from each client
=================================================================
We recommend that you design each client to use one connection to a Microsoft Jet database. Each connection to a Jet database represents an independent client to the database, even when these connections come from the same client process.
To optimize performance and network I/O and to reduce the multi-user stress on the back-end database, design the client application to use a single connection to the Jet database. Share this connection over multiple record sets as required. This has the added benefit of preventing read delays and write delays in the client application. By default, there is a five-second delay between writing a value to the database and being able to read this updated value when writing and when reading on two different Jet connections. This is true even if the two connections reside in the same client process. If you use a single connection, you avoid this issue.
Use ADO to access a Microsoft Jet database
==========================================
When you access a Microsoft Jet database from ADO, we recommend that you use the Microsoft Jet OLE DB Provider instead of the Microsoft Access ODBC driver. For more information about this topic, click the following article number to view the article in the Microsoft Knowledge Base: 299974 Using Microsoft Jet with IIS
Move to a transactional database engine to gain additional integrity
====================================================================
Unlike a file-based database engine, a server-based database engine, such as Microsoft SQL Server, processes all the multiple-client requests to a database at the server. The server keeps track of these requests in a transaction log. If a request cannot be fulfilled, the server rolls back the request or does not process the request. This reduces the risk that the database is left in an incomplete state or in a corrupted state.
Before you upgrade from a file-based database engine to a server-based database engine, you must consider the advantages and the disadvantages of doing so. For more information about choosing the most appropriate database engine for your purposes, click the following article number to view the article in the Microsoft Knowledge Base:
168549 Choosing the appropriate database white paper available in Download Center
Note Although this white paper is written for Access 97, this white paper also applies to Jet 4.0 and Access 2000.
September 15, 2015 at 10:09 am
So you have the access level defined somewhere - how do you secure THAT .MDB to prevent someone from tampering? etc.
You'll have to ask Garry Robinson, or consult his book(I referenced in earlier post), to get complete details of how this is done.
Just know that Garry demonstrates how you can use the NTFS based Operating System to secure the folders where the *.MDB files are, maintain the ability for users of that Group to modify the records within the *.MDB files from your ODBC-enabled DB application user-interface, maintain the ability of the *.MDB lock files to be deleted, prevent ANY USER (except the SYS and DB ADMINs) from LISTING the contents of that folder(s) and COPYING/MOVING/DELETING *.MDB files, or otherwise such as LINKING to these files.
I have not implemented this security myself, so I am not prepared to explain it to anyone in detail.
Although I plan to continue reading about it in Garry's book to educate myself, I plan on having the Windows O/S Server System Admin person to set this up with help from Garry's book instructions.
I do not plan to password protect individual *.MDB files. nor use MS-Access Workgroups which I believe both utilize the system.MDW file.
I also do not plan on using persistent ODBC connections, nor the record locking built into Jet Engine, but using my own strategy whereby I update a column in a table with the username of the user placing a lock on a record opened in EDIT MODE, and then release the lock when changes are saved or abandoned (SAVE/CANCEL). Any child table rows associated with a parent table row would not need to be manually locked as long as you design your system so that child table rows are only accessed for EDIT whenever the associated parent table row is manually locked for edit.
I also plan to have all BATCH Operations such as heavy maintenance of many-many rows performed Server-side off hours by Operations Staff. Client-side maintenance will be restricted to 1 or a few records/rows at a time (as in a parent/child table relationship i.e. 1-to-many). REMEMBER, in my system, rows are MARKED for delete only with an UPDATE SQL statement, then deleted(DELETE) at the time just before a file reorganization (JetComp.exe) is periodically executed. ADDS/INSERTS, if not BATCH, are inserted into a single *.MDB file (with growth to 10 million rows approx.), then merged with the entire database just before the file reorganization (JetComp.exe) is periodically executed. If you have both a Primary Index Key, and Alternate Index Keys, you may have to prevent update to columns in an Alternate Index Key (via end-user maintenance screens) to prevent these indexes from becoming inefficient. You could allow their update, but in doing so, you likely will have to run JetComp.exe daily, which on a very large database of 100s of *.MDB files, would likely be too daunting a task unless you can squeeze this in overnight (off hours) via batch processes not interfering with scheduled batch updates and large detail report processing.
September 15, 2015 at 10:45 am
erichansen1836 (9/15/2015)
WHEN TO USE:SQL SERVER
========
* For Network or non-Network Databases larger than 5 Terabytes and 25 Billion rows - use SQL Server
* For Network Databases smaller than 5 Terabytes and 25 Billion rows, but with heavy client-side concurrent
maintenance and queries being performed (or potentially performed) by 100s or 1000s of users
- use SQL Server
* For Read/Write Databases used over a WAN (wide area network) - use SQL Server.
* For Corporations where Network Databases are in the 10s of Gigabytes (or more), and money is no object
for hiring highly trained SQL Server Admins and purchasing SQL Server products and licensing for the
entire Enterprise - use SQL Server.
JET ENGINE
========
* For Database situations NOT listed above (i.e. for SQL SERVER) - use Jet Engine (FREE/NO COST)
MICROSOFT RECOMMENDS: https://support.microsoft.com/en-us/kb/303528
from ARTICLE: How to keep a Jet 4.0 database in top working condition
Use a robust file server
==============
Make sure that you have a robust file server that can handle the number of users and the requests that are being made to the Microsoft Jet database file. Additionally, make sure that the file server is not overtaxed with handling other processes, such as acting as a Windows domain controller, an Exchange server, or a SQL Server.
A problem also occurs if you restart the server to fix a problem with another important service, such as the mail service. Problems also occur when you restart the server after you apply new software or you apply a service pack or a hotfix, and you forget that the Microsoft Jet database is currently shared on the server. When the file server is restarted, unexpected interruption of the client connections to the database occur. This may cause database corruption. To prevent interrupted client connection, all clients must close the database before the file server is restarted or before software updates to the file server are applied.
A file server must also be put in a secured location where the file server cannot be accidentally switched off. The server must have an uninterrupted power supply (UPS) to help protect from intermittent power outages or from power fluctuations. The network file server must also have the following:
High-performance hard drives
A high-quality network card
Lots of RAM to make sure that the server can handle the load
Verify network connectivity
===========================
Make sure that you have a stable network and a fast network with stable network connectivity to the network file server. We recommend that you do not use Microsoft Jet over a WAN, over a modem connection, or over FTP, or any other less-than-reliable network transport. Because Microsoft Jet is a file-sharing database system, any less-than-reliable network transport increases the chances of a dropped client. This can increase the chance of database corruption.
Minimize the number of connections that are made from each client
=================================================================
We recommend that you design each client to use one connection to a Microsoft Jet database. Each connection to a Jet database represents an independent client to the database, even when these connections come from the same client process.
To optimize performance and network I/O and to reduce the multi-user stress on the back-end database, design the client application to use a single connection to the Jet database. Share this connection over multiple record sets as required. This has the added benefit of preventing read delays and write delays in the client application. By default, there is a five-second delay between writing a value to the database and being able to read this updated value when writing and when reading on two different Jet connections. This is true even if the two connections reside in the same client process. If you use a single connection, you avoid this issue.
Use ADO to access a Microsoft Jet database
==========================================
When you access a Microsoft Jet database from ADO, we recommend that you use the Microsoft Jet OLE DB Provider instead of the Microsoft Access ODBC driver. For more information about this topic, click the following article number to view the article in the Microsoft Knowledge Base: 299974 Using Microsoft Jet with IIS
Move to a transactional database engine to gain additional integrity
====================================================================
Unlike a file-based database engine, a server-based database engine, such as Microsoft SQL Server, processes all the multiple-client requests to a database at the server. The server keeps track of these requests in a transaction log. If a request cannot be fulfilled, the server rolls back the request or does not process the request. This reduces the risk that the database is left in an incomplete state or in a corrupted state.
Before you upgrade from a file-based database engine to a server-based database engine, you must consider the advantages and the disadvantages of doing so. For more information about choosing the most appropriate database engine for your purposes, click the following article number to view the article in the Microsoft Knowledge Base:
168549 Choosing the appropriate database white paper available in Download Center
Note Although this white paper is written for Access 97, this white paper also applies to Jet 4.0 and Access 2000.
What is the link for the document that you copied the above from?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 15, 2015 at 10:48 am
https://support.microsoft.com/en-us/kb/303528
ARTICLE: How to keep a Jet 4.0 database in top working condition
September 15, 2015 at 10:54 am
erichansen1836 (9/15/2015)
WHEN TO USE:SQL SERVER
========
* For Network or non-Network Databases larger than 5 Terabytes and 25 Billion rows - use SQL Server
* For Network Databases smaller than 5 Terabytes and 25 Billion rows, but with heavy client-side concurrent
maintenance and queries being performed (or potentially performed) by 100s or 1000s of users
- use SQL Server
* For Read/Write Databases used over a WAN (wide area network) - use SQL Server.
* For Corporations where Network Databases are in the 10s of Gigabytes (or more), and money is no object
for hiring highly trained SQL Server Admins and purchasing SQL Server products and licensing for the
entire Enterprise - use SQL Server.
JET ENGINE
========
* For Database situations NOT listed above (i.e. for SQL SERVER) - use Jet Engine (FREE/NO COST)
MICROSOFT RECOMMENDS: https://support.microsoft.com/en-us/kb/303528
from ARTICLE: How to keep a Jet 4.0 database in top working condition
Use a robust file server
==============
Make sure that you have a robust file server that can handle the number of users and the requests that are being made to the Microsoft Jet database file. Additionally, make sure that the file server is not overtaxed with handling other processes, such as acting as a Windows domain controller, an Exchange server, or a SQL Server.
A problem also occurs if you restart the server to fix a problem with another important service, such as the mail service. Problems also occur when you restart the server after you apply new software or you apply a service pack or a hotfix, and you forget that the Microsoft Jet database is currently shared on the server. When the file server is restarted, unexpected interruption of the client connections to the database occur. This may cause database corruption. To prevent interrupted client connection, all clients must close the database before the file server is restarted or before software updates to the file server are applied.
A file server must also be put in a secured location where the file server cannot be accidentally switched off. The server must have an uninterrupted power supply (UPS) to help protect from intermittent power outages or from power fluctuations. The network file server must also have the following:
High-performance hard drives
A high-quality network card
Lots of RAM to make sure that the server can handle the load
Verify network connectivity
===========================
Make sure that you have a stable network and a fast network with stable network connectivity to the network file server. We recommend that you do not use Microsoft Jet over a WAN, over a modem connection, or over FTP, or any other less-than-reliable network transport. Because Microsoft Jet is a file-sharing database system, any less-than-reliable network transport increases the chances of a dropped client. This can increase the chance of database corruption.
Minimize the number of connections that are made from each client
=================================================================
We recommend that you design each client to use one connection to a Microsoft Jet database. Each connection to a Jet database represents an independent client to the database, even when these connections come from the same client process.
To optimize performance and network I/O and to reduce the multi-user stress on the back-end database, design the client application to use a single connection to the Jet database. Share this connection over multiple record sets as required. This has the added benefit of preventing read delays and write delays in the client application. By default, there is a five-second delay between writing a value to the database and being able to read this updated value when writing and when reading on two different Jet connections. This is true even if the two connections reside in the same client process. If you use a single connection, you avoid this issue.
Use ADO to access a Microsoft Jet database
==========================================
When you access a Microsoft Jet database from ADO, we recommend that you use the Microsoft Jet OLE DB Provider instead of the Microsoft Access ODBC driver. For more information about this topic, click the following article number to view the article in the Microsoft Knowledge Base: 299974 Using Microsoft Jet with IIS
Move to a transactional database engine to gain additional integrity
====================================================================
Unlike a file-based database engine, a server-based database engine, such as Microsoft SQL Server, processes all the multiple-client requests to a database at the server. The server keeps track of these requests in a transaction log. If a request cannot be fulfilled, the server rolls back the request or does not process the request. This reduces the risk that the database is left in an incomplete state or in a corrupted state.
Before you upgrade from a file-based database engine to a server-based database engine, you must consider the advantages and the disadvantages of doing so. For more information about choosing the most appropriate database engine for your purposes, click the following article number to view the article in the Microsoft Knowledge Base:
168549 Choosing the appropriate database white paper available in Download Center
Note Although this white paper is written for Access 97, this white paper also applies to Jet 4.0 and Access 2000.
Answer me this, who is going to maintain your work when you are no longer around to do so? Are you training others to provide support? Do you expect others to pick up Garry's book and continue on?
Me personally, I'd walk away for any company using your database system. I have no desire to learn how to code and support the intricacies that are taken care of for me by SQL Server/Oracle/PostgreSQL/MySQL/Name your commercial RDBMS. I'll learn what I need to know about the internals to maximize performance, but I don't want to dive into and write the code.
September 15, 2015 at 10:57 am
erichansen1836 (9/15/2015)
https://support.microsoft.com/en-us/kb/303528ARTICLE: How to keep a Jet 4.0 database in top working condition
Make the link clickable:
September 15, 2015 at 11:08 am
The OP seems to be looking for justification of his personal decisions regarding architecture.
Sure, stick with this system. It will work. Will anyone else be able to help support it?
Michael L John
If you assassinate a DBA, would you pull a trigger?
Yes. and No.
For my own purposes, Yes.
But I would not recommend it written/maintained in Win32 Perl for organizations I did not work for.
You can use a more popular programming language and I suppose ODBC or OLEDB?
What I hope everyone takes away from this is not that I am making a Win32 Perl RDBMS, which utilizes Jet Engine, as if I were going to SELL it for general use to compete with SQL SERVER.
No, what I am demonstrating is that anyone can build as simple or sophisticated a RDBMS as they wish, utilizing Jet Engine and a *.MDB file system, for small/medium/huge databases up into the multi-billions of rows. *.MDB files can act as partial tables and not as databases in and of themselves limited to 2 GIG in size.
Jet Engine offers lots of data type options, indexing, ODBC connectivity, etc. And free file recovery tools within JetComp.exe utility.
Not as sophisticated as SQL Server, but well able to handle concurrent multi-user traffic over a network.
Well able to handle lots of data. And you can use built in functionality like record locking and referential integrity (e.g. cascading deletes/updates via constraints) or use your own manual methods. And you can wrap related SQL maintenance events within an ODBC transactions and Commit or Rollback the work so that ALL or NONE of the changes take place. ERROR Trapping is easy with ODBC.
===================
Seems like a NO-BRAINER to me to use Jet Engine for huge READ ONLY Network share databases that require only a GUI "report criteria selection screen" be built for end-user custom reporting purposes. Such a database could be refreshed periodically with updates by Batch operations done Server-side during non-business hours. And if major reporting is to be done, also do it Server-side. This type of database would be fine too for CSR (Customer Service Request) lookups during business hours.
September 15, 2015 at 11:13 am
erichansen1836 (9/15/2015)
The OP seems to be looking for justification of his personal decisions regarding architecture.
Sure, stick with this system. It will work. Will anyone else be able to help support it?
Michael L John
If you assassinate a DBA, would you pull a trigger?
Yes. and No.
For my own purposes, Yes.
But I would not recommend it written/maintained in Win32 Perl for organizations I did not work for.
You can use a more popular programming language and I suppose ODBC or OLEDB?
What I hope everyone takes away from this is not that I am making a Win32 Perl RDBMS, which utilizes Jet Engine, as if I were going to SELL it for general use to compete with SQL SERVER.
No, what I am demonstrating is that anyone can build as simple or sophisticated a RDBMS as they wish, utilizing Jet Engine and a *.MDB file system, for small/medium/huge databases up into the multi-billions of rows. *.MDB files can act as partial tables and not as databases in and of themselves limited to 2 GIG in size.
Jet Engine offers lots of data type options, indexing, ODBC connectivity, etc. And free file recovery tools within JetComp.exe utility.
Not as sophisticated as SQL Server, but well able to handle concurrent multi-user traffic over a network.
Well able to handle lots of data. And you can use built in functionality like record locking and referential integrity (e.g. cascading deletes/updates via constraints) or use your own manual methods. And you can wrap related SQL maintenance events within an ODBC transactions and Commit or Rollback the work so that ALL or NONE of the changes take place. ERROR Trapping is easy with ODBC.
And who ever does this needs to know the amount of work they are going to get into make a viable system that not many others could simply walk into and maintain when they leave to go elsewhere, including retirement.
Viewing 15 posts - 46 through 60 (of 245 total)
You must be logged in to reply to this topic. Login to reply