RSViewSE Report Generation

[manav 0]

I had written a vba code in Excel to generate an hourly report for data in RSView32 4 yrs ago. After lots of debugging, the application has been working successfully at 100+ sites for the last 4 yrs. This year we are deploying RSViewSE at 5+ sites. I need to develop an application for reporting in RSViewSE for these sites. I have been reading up on related material. I have searched the help, read the manual, looked at the technotes, but the information for this is somewhat limited. I have 2 approaches in mind: - To somehow get the data in dbf format from RSViewSE. Then use the already developed vba app for RSView32 with some modifications for report generation. - To log into odbc database like Access. Then either write code in access or in excel to get a report from this data. Has anyone done any work on this earlier? Any pointers so I can focus in the right direction? Currently I am trying to write a vba code from a screen to create a trend snapshot with the report data, which comes out in dbf format. If successful then I can use this data to generate a report in Excel. I have not been able to find out how to log data into Access (ODBC format). How can I do so? Can I log data in Excel directly in ODBC format? While trying to create a trend snapshot thru VB programming my VB compiler gave some errors and I lost the code for the screen and had to re-write the code. Any patches or updates I need for VBA in RSViewSE ver 4.00 CPR7? Any VB gurus please feel free to help here!!

[Nathan 7]

Use Access, or better yet, a real SQL database. Since you're into VBA programming, you can actually write very cool/powerful GUI frontends in MSAccess that connect via ODBC. The weaker part of access is the underlying database engine (still better than .dbf approach). If you're going to invest the time to custom program this, I'd recommend using MS SQL Server as the backend. It will scale better, particularly for: backups, maintenance, and as users/data grows. You can accomplish similar programming within MS Excel. The SQL approach gives the additional option of Reporting packages from MS or others like Crystal Reports. Another nice feature of using a powerful database is that you don't need to generate an "hourly" report per say. You can create a window where the end user decides on the report type, duration, etc, and the "view" is dynamically generated at the users request. I don't know if a .dbf database satisfies this requirement or not. A properly indexed SQL database can quickly deliver LOTS of sorted data. Even Access will do well here. AB should have plenty of ways of getting data to an SQL/Access database. Hopefully it's builtin or a simple plugin. Depending on what you're doing, you might need Historian, Plantmetrics, or RSSQL. You could also use a 3rd party program to get data into the database like FactorySQL.

[manav 0]

Thanks mate. The info is helpful. But problem still is that I have not been able to get any info on logging data directly into MSAccess or MSExcel using ODBC data logging in RSViewSE. What I have done in the meantime is code some VBA in RSViewSE and MSExcel to develop a reporting application that logs data in SE Server in .dbf format, and then use Excel to manipulate this data and generate the report. It is almost completed and in its final debugging stage. Hope to have it ready for shipping in a couple of weeks. I still find Excel the best method to develop a reporting app as the cost of Excel is quite low for client to invest in it, plus most clients already have MSOffice running in their plants, so it is quite easy for the client to install and maintain. I had developed a similar app for RSView32 some yrs back. Prior to that my firm was outsourcing the reporting app, which was VB based. Needless to say the cost was quite high and the app was quite difficult for the client and our engineers to install and maintain. We had to rely on the firm providing the VB app for even the simplest of support issues. Since shifting to the Excel based VBA app for RSView32, I have had no problems with it at 100+ sites for last 4 yrs. Also our engineers can deploy the same after just a few hours of training on the same. All the controls for the formatting of the report are Excel / RSView based, so a person without any knowledge of VBA can easily deploy the app, after a few hours of training. So far I am just shipping these apps with RSView32 installations. I am interested in finding a market for these products independent of our install base. Any suggestions for that?

[Kah Chun 0]

Manav, not too sure if this going to help you much but as Nathan has suggested I reckon it's better off to use an SQL as the backend both for storage and logging of information. In our plant, we use MSSQL as storage and RSSQL as the transaction manager. Reports, when required are generated through RSBizWare or through normal queries directly from the server itself. Alternatively, provided you have the user rights, you can also make query to SQL via Excel. This way, you can utilised the flexibility and adaptability of RSBizWare or Excel in generating reports and the secure and powerful storage and database management of the SQL. That's all I get help you as I'm not really good with VBA. Good luck...