System configuration chart
- Number of Forms (Including Sub-forms): 200
- Number of Tables: 120
- Number of Queries: 100
- Number of Reports: 40
- The number of Macro Default: 2
- Development started: March 2015(Development period: Two months, Test operation: Two months)
- Full operation: July 2015
Business Support System
Our Administrative Headquarters employed the dbSheetClient for Access to construct the "Business Support System" that the sales managers and the sales assistants use.
This system let our 10 domestic bases use MS-Access applications smoothly which cover quotations, order forms, and other forms up to issuing invoices that the sales managers create.
In fact, our company uses SAP as the backbone system. Since the SAP begins with its business processes after orders are received, neither it cannot digitize data of sales leads nor it has the features to conduct various sales information data search such as delivery due.
Now we manage database of the sales activities from sales leads to the order acceptance by digitizing data where usually it is not easy to do so, and then deliver the database to the SAP for the orders/sales processing.
The accounting processing is then handled by SAP. Thus this Access System is a business support system to support all aspects of the sales operations.
Issues/requests for the system introduction
There are 10 locations to use the support system. The Access system, after all, is based on personal use, which is a useful tool for the local environment, but it is difficult to apply to the centralized management. So, each place made copies of the system and deployed them with each module and database as sets.
From the viewpoint of the company's top management, it is pointed out that the system does not have enough capacity to cope with the company's growing sales activities.
Moreover, there is a 2GB limitation of the MDB size that Access can handle in which we need to keep the past 10 years data which is required by tax law. Beside the tax law requirement, each time we deal with an inquiry concerning the customer's past business transaction, the volume of data increases.
From the above two reasons, we had an uneasy feeling to manage a mass volume of data, and the fact that each business location uses its own module leads to an increased operational cost.
In recent years, the biggest problem we faced was an increase of the consumption tax from 5% to 8%, which demands all business locations to cope with the change.
This necessity prompted our company to seek a way for the centralized management.
Reason we have adopted dbSheetClient for Access
Out of many candidates, we picked up 3 companies to have them demonstrate their cloud type packaged systems. We then had operators (users) who conducted the data entries in our company to evaluate the packages. In their opinion, there was a great gap in appearance between the operations they were used to the Access system and the operation of the packaged system, and it would probably take a substantial time to bridge the gap.
Afterwards, we asked one of our group companies which is specialized in the system development to give us a quotation to remake an Access based program, then we were introduced to contact NEWCOM, Inc., which has the dbSheetClient for Access. We learned that the introduction of the package system would require a substantial time to bridge the gap between the Access based operation and the package system operation. NEWCOM, Inc. then understood our needs for the database management and the centralized management, and convinced us that their dbSheetClient based Access application is the best solution for our case. Thus, we decided to employ the Newcom's system for the following reasons.
- (1) Allow us the centralized database management → You can manage data with a powerful database of the server.
- (2) Each module (program) may be delivered automatically via the server.
- (3) You can centralize (from one location) the operational management and maintenance as the system to build the internal governance.
Up to now, the Access System program at each business location became an independent program as soon as the program is copied. While managing the module (program) at each location, if a big event (such as consumption tax rate changes) occurs, a certain volume of work, multiplied by the number of bases, will be generated. Even solving this headache alone was a great merit.
Process and introduction effect of the system introduction and development
At first we participated in Newcom's presentation seminar in November 2014. After receiving the system proposal directly from Newcom, we introduced the system in February 2015.
We received education of the dbSheetClient for Access Program in the end of February, and incorporated the Access APIs that Newcom provided in March and April, then conducted a test run for two months at two bases which belong to the Headquarters, and moved to the full operation in July.
As a developer, I rely on "CockpitViewer" and "ServerLogViewer" a lot to modify the system.
The "CockpitViewer" is to examine the Database Update situation. The "CockpitViewer" is excellent in GUI, and you can search data without knowing how to write SQL sentence.
Moreover, the SQL sentence is displayed when you search, which helps you to learn. The SQL sentence made from GUI can be modified, and written onto Excel easily.
We start up the "ServerLogViewer," when the system’s instability is noticed, and watches the processes from the morning to check error occurrences. If a user is not paying attention to an error, even when it occurs, it is often not reported to the developers and then, often there is a delay to fix the bugs. The "ServerLogViewer," then, helps us a lot to detect errors.
Screen sample of CockpitViewer
It is a viewer that the System Administrator and developers can use to browse the centralized Server Database. (You can view the content of tables by selecting different DB such as SQL Server and Oracle by Combo Box only) The basic features that the "CockpitViewer" provides are as follows.
The basic features that the "CockpitViewer" provides are as follows.
- (1) You can refer to the "Database" lists which are already registered to the dbSheetClient Server, as well as the table lists and records of each Database.
- (2) Compatible databases (DBMS) are SQLServer, Oracle, MySQL(ODBC) and PostgreSQL(ODBC).
- (3) You can refer to the result of the SQL to the connected Database with a tabular form.
- (4) You can refer to the View in each Database and the result of the stored procedure.
- (5) You can display the listed records as "Excel" data and save it as an Excel file.
- (6) Various search methods (forward match, partial match, fuzzy match) are available.
Screen sample of ServerLogViewer
This is a viewer that, when a user logs in to the dbSheetClient Server, you can check the operational log of the user from start of executing a project till the user is logged off.
Log information will be recorded when the following operations are conducted.
- (1) Login time(Since a project is not selected, the project name is blank)
- (2) When the execution of the project is started in Runtime/Development Component
- (3) When the execution of the project is ended in Runtime/Development Component
- (4) When Save/Print is executed in the Runtime Component
- (5) When unauthorized Save/Print/End process is attempted by using short cut key in the Runtime Component
- (6) When "Write Log" i.e. adding certain system behavior record in the log conducted from the Runtime Component (To record certain system behavior other than listed above in an execution environment i.e. from the Runtime Component, the definition file must be designed as such by using task types in Development Component.)
- (7) When various types upload, such as project definition information, is executed in the Development Component
- (8) Logoff time (When it returns to the login screen)
- (9) Terminal logoff time (When the dbSheetClient is exited)
- (10) When an error occurs when executing it in the Execution Version
- (11) When the file up-loading is executed in the Execution Version
- (12) When the file download is executed in the Execution Version
- (13) When an error occurs while executing it
- (14) When SQL statement execution is processed in the Execution/Development Version
From the Administrator's viewpoint, when you need to update terminal programs at different locations, you only need to upload the modified module to the server, then the update is automatically conducted. This makes my job much easier than before.
Before, when we modified a module (program), I informed each location about the need to update the module, then sent them a copied module for switch, and follow up to see if they updated it properly. It was quite an exhausting process to make sure everyone did the right job.
This work process became one tenth of what it used to be. This is the merit by the centralized management (from the Headquarters) for the operational management and maintenance.
For the system users, too, that they could use the system as if they are using a familiar system so that the transition from the old system to the new system was done very smoothly with little stress and discomfort compared to introducing different systems we considered before.
Initially, we examined the introduction of cloud type packages, but it would have taken substantial cost and man hours to adopt such a system. I think that the dbSheetClient for Access is a revolutionary tool to give a new life to existing Access based system.
About the future
We still have several Access based systems in our company which are not incorporated to dbSheetClient for Access. It will take probably another 6 months to complete the development with dbSheetClient for Access. We also have Excel based routine operations in our company. We will build a new operational system with the dbSheetClient for Excel to improve our operational efficiency.