At this stage, I have tested the command files mostly with
MySQL.
Would you or any other be interested in checking out other
SQL implementations?
In the reply to your bug report (1214613), I also indicated
that I would also like to interact directly with various
RDBMSs. Is that of interest to you or anyone else?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't currently have a MySQL installation. Most readily
available I have access to MS Access, MSDE and MS SQL
Server. I attempted to use the generated SQL file with MSDE
and it didn't like the flavor.
I would be willing to test with MSDE or MS Access if that
would be useful.
I will look into setting up a MySQL install for short-term
testing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would be delighted to have you develop and test a version
of the SQL command files that would work with MS Access and
MS SQL. As currently implemented, there is a "template" file
in sqltemplate.py that I use as the basis for the SQL that
is generated. I may need to be modified to handle the type
of SQL that MS uses.
BTW, I may not have been clear - which means the
documentation needs improving ;-), but without the -N
option, each subsequent PyMetrics run appends the current
results to the existing command file (defaults to
metricData.sql and metricData.csv). Also, each run has a
unique ID on every INSERT line of the SQL command file. This
was meant to allow you to track changes to the same
program(s) over time.
Thanks.
Reg.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Communicating directly with the database has advantages, but
it could also make your application more complex.
There are the issues of which flavor of database you are
connecting to, where (on which computer / server) the
database resides, authentication issues, database naming for
servers that support more than one database at a time...
I think that the SQL output option will still be used by
some users, even if you can connect directly to the database.
As I stated earlier, I have access to and I am willing to do
testing with MSDE and/or MS Access.
(I also have access to a full MS SQL Server installation,
but availability for testing is limited. MSDE is
sufficiently like SQL Server that we have successfully run
the same SQL on both.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=411372
At this stage, I have tested the command files mostly with
MySQL.
Would you or any other be interested in checking out other
SQL implementations?
In the reply to your bug report (1214613), I also indicated
that I would also like to interact directly with various
RDBMSs. Is that of interest to you or anyone else?
Logged In: YES
user_id=135065
I don't currently have a MySQL installation. Most readily
available I have access to MS Access, MSDE and MS SQL
Server. I attempted to use the generated SQL file with MSDE
and it didn't like the flavor.
I would be willing to test with MSDE or MS Access if that
would be useful.
I will look into setting up a MySQL install for short-term
testing.
Logged In: YES
user_id=411372
Hi Robert,
I would be delighted to have you develop and test a version
of the SQL command files that would work with MS Access and
MS SQL. As currently implemented, there is a "template" file
in sqltemplate.py that I use as the basis for the SQL that
is generated. I may need to be modified to handle the type
of SQL that MS uses.
BTW, I may not have been clear - which means the
documentation needs improving ;-), but without the -N
option, each subsequent PyMetrics run appends the current
results to the existing command file (defaults to
metricData.sql and metricData.csv). Also, each run has a
unique ID on every INSERT line of the SQL command file. This
was meant to allow you to track changes to the same
program(s) over time.
Thanks.
Reg.
Logged In: YES
user_id=135065
Communicating directly with the database has advantages, but
it could also make your application more complex.
There are the issues of which flavor of database you are
connecting to, where (on which computer / server) the
database resides, authentication issues, database naming for
servers that support more than one database at a time...
I think that the SQL output option will still be used by
some users, even if you can connect directly to the database.
As I stated earlier, I have access to and I am willing to do
testing with MSDE and/or MS Access.
(I also have access to a full MS SQL Server installation,
but availability for testing is limited. MSDE is
sufficiently like SQL Server that we have successfully run
the same SQL on both.)