Feature request: centralized database logging

[SiliconDragon]

GPUZ is great as a standalone utility, but it could easily be enhanced to log data to a centralized database as well. Would you please consider adding this feature:

Settings:

1. Database logging checkbox; when checked:
   1. Database type (maybe just a connection string and an icon link to connectionstrings.com for add'l info)
   2. Database location (server, instance name, etc.)
   3. Login, typically userid + pswd, but could include checkbox if using a network acct (e.g. ActiveDirectory)
   4. Database name (with default of GPUZ)
   5. Frequency of data pushes (realtime, 60s, hourly, etc.)

If need be, I could assist with the coding or send you a C# SQL class I often use for utilities of my own, complete with script to create the database and a login. If you're coding in Java, a C# translation isn't difficult, C++ is a bit more involved. My databases are SQL Server; if you prefer mysql, postgresql, etc., your mileage may vary.

 

[W1zzard]

Write some kind of wrapper that pulls the data from GPU-Z shared memory and writes it to your database?

 

[SiliconDragon]

The exact method depends on how the GPUZ code is designed. I often use a C# class which is a 1-line addition to any .NET app, but the code could easily be ported to another language, e.g. C++ or Java. (I don't know what GPUZ uses.) My class uses a config file setting for database redirection, else it defaults to LOCALHOST. I could provide scripts to create a SQL Server database called GPUZ, a stored procedure to call to log stats, another sproc to query for logged stats, and a login+user to make the database connection. My class already has wrappers around the actual database calls, exception handling, and even some support classes for easy manipulation of returned recordsets (i.e. collection objects, and serializers for TXT, CSV, TSV, JSON, and HTML).

My class isn't needed, it's just convenient. In fact, most of the support classes aren't intended for high-performance usage. The core code, however, is robust and efficient.

The advantage of using a database is so the code can store data in a centralized location, keyed by machine name + timestamp, so it's easily queried for monitoring and reporting purposes.

Again, I only suggest SQL Server because there's a free version, it's reliable, and easy to maintain. (It's also better optimized for write/edit than mysql, though postgresql is as well, although I haven't coded with it for eons.)

 

[Aquinus]

Write some kind of wrapper that pulls the data from GPU-Z shared memory and writes it to your database?

To the OP: This is the generic way of doing it, as it lets you do anything with the data whenever you want it which requires W1zz to do zero work. So to play devil's advocate, why would this need to exist in GPU-Z when it could be another application that simply reads shared memory? I like the idea of logging to a database but, most people aren't going to have a SQL server installed. If you wanted to do this right, I would support several different kinds out of the box (if they're installed,) but being able to fallback on something like SQLite incase nothing is available. Personally I like PostgreSQL and think it's one of the best options RDBs but, has a steeper learning curve than MySQL.

@W1zzard : Do you have any documentation on that shared memory for the OP and for the benefit of the thread if you do?

 

[SiliconDragon]

Devil's advocate 2.0: why 2 apps? That'd be like having a separate app to log data in the 1st place. I'm simply suggesting a centralized storage facility using industry standards.

Does GPUZ have a plugin interface? That's a much better standard to follow.

2 apps sharing RAM... That sounds only slightly better than porcupines mating.