From info at egenix.com Mon Mar 25 11:10:30 2013 From: info at egenix.com (eGenix Team: M.-A. Lemburg) Date: Mon, 25 Mar 2013 11:10:30 +0100 Subject: [DB-SIG] ANN: eGenix mxODBC 3.2.2 - Python ODBC Database Interface Message-ID: <51502296.8040503@egenix.com> ________________________________________________________________________ ANNOUNCING eGenix.com mxODBC Python ODBC Database Interface Version 3.2.2 mxODBC is our commercially supported Python extension providing ODBC database connectivity to Python applications on Windows, Mac OS X, Unix and BSD platforms This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-mxODBC-3.2.2-GA.html ________________________________________________________________________ INTRODUCTION mxODBC provides an easy-to-use, high-performance, reliable and robust Python interface to ODBC compatible databases such as MS SQL Server, MS Access, Oracle Database, IBM DB2 and Informix , Sybase ASE and Sybase Anywhere, MySQL, PostgreSQL, SAP MaxDB and many more: http://www.egenix.com/products/python/mxODBC/ The "eGenix mxODBC - Python ODBC Database Interface" product is a commercial extension to our open-source eGenix mx Base Distribution: http://www.egenix.com/products/python/mxBase/ ________________________________________________________________________ NEWS The 3.2.2 release of our mxODBC is the latest patch level release of our popular Python ODBC Interface. In this release, we've included the following the following enhancements and fixes: Feature Enhancements -------------------- * Backported the new .cursortype attribute from the upcoming mxODBC 3.3. The new attribute allows easily adjusting and inspecting the ODBC cursor type to be used for an mxODBC cursor object. The reason for this unusual backport and inclusion in a patch level release is that we found a serious performance issue with MS SQL Server when using it with mxODBC 3.2 (see below). This needed to be addressed immediately. Driver Compatibility -------------------- * MS SQL Server performance can now be much enhanced, and increased to levels beyond that of mxODBC 3.1 and previous releases, by adjusting the default cursor type to forward-only cursors: connection = mx.ODBC.Windows.DriverConnect(...) connection.cursortype = mx.ODBC.Windows.SQL.CURSOR_FORWARD_ONLY # Cursors created on this connection will then default to forward # only cursors, instead of the mxODBC 3.2 default for SQL Server # of using static cursors cursor = connection.cursor() The performance increase compared to mxODBC 3.2.1 is enormous: from 2-3x faster executes/fetches for average queries, up to 300x faster for simple cases. In mxODBC 3.3, we will switch to using forward-only cursors per default for all database backends. * IBM DB2 can benefit from the same performance enhancements using forward-only cursors. The effect is a lot smaller, but still noticeable: up to 2x faster executes/fetches with forward-only cursors, compared to mxODBC 3.2.1. * Added documentation to explain the different cursor types, compatibility with different database backends and effects on performance. Fixes ----- * Fixed a problem with using mxODBC cursors as context managers: these worked fine in Python 2.6, but had stopped working in Python 2.7 due to changes in the Python internals. For the full set of changes please check the mxODBC change log: http://www.egenix.com/products/python/mxODBC/changelog.html ________________________________________________________________________ FEATURES mxODBC 3.2 was released on 2012-08-28. Please see the full announcement for highlights of the 3.2 release: http://www.egenix.com/company/news/eGenix-mxODBC-3.2.2-GA.html For the full set of features mxODBC has to offer, please see: http://www.egenix.com/products/python/mxODBC/#Features ________________________________________________________________________ EDITIONS mxODBC is available in these three editions: * The low-cost Standard Edition which provides data connectivity to a single database type, e.g. just MS SQL Server. * The Professional Edition, which gives full access to all mxODBC features. * The Product Development Edition, which allows including mxODBC in applications you develop. Compared to mxODBC 3.0, we have simplified our license terms to clarify the situation on multi-core and virtual machines. In most cases, you no longer need to purchase more than one license per processor or virtual machine, scaling down the overall license costs significantly compared to earlier mxODBC releases. For a complete overview of the new editions, please see the product page. http://www.egenix.com/products/python/mxODBC/#mxODBCEditions ________________________________________________________________________ DOWNLOADS The download archives and instructions for installing the package can be found at: http://www.egenix.com/products/python/mxODBC/ In order to use the eGenix mxODBC package you will first need to install the eGenix mx Base package: http://www.egenix.com/products/python/mxBase/ ________________________________________________________________________ UPGRADING Users are encouraged to upgrade to this latest mxODBC release to benefit from the new features and updated ODBC driver support. We have taken special care, not to introduce backwards incompatible changes, making the upgrade experience as smooth as possible. Customers who have purchased mxODBC 3.2 license can continue to use their licenses with this patch level release. Customers who have purchased mxODBC 2.x, 3.0 or 3.1 licenses, can benefit from upgrade discounts. We will give out 20% discount coupons going from mxODBC 2.x to 3.2 and 50% coupons for upgrades from mxODBC 3.x to 3.2. After upgrade, use of the original license from which you upgraded is no longer permitted. Please contact the eGenix.com Sales Team at sales at egenix.com with your existing license serials for details for an upgrade discount coupon. If you want to try the new release before purchace, you can request 30-day evaluation licenses by visiting our web-site http://www.egenix.com/products/python/mxODBC/#Evaluation or by writing to sales at egenix.com, stating your name (or the name of the company) and the number of eval licenses that you need. _______________________________________________________________________ SUPPORT Commercial support for this product is available from eGenix.com. Please see http://www.egenix.com/services/support/ for details about our support offerings. _______________________________________________________________________ INFORMATION About Python (http://www.python.org/): Python is an object-oriented Open Source programming language which runs on all modern platforms. By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for today's IT challenges. About eGenix (http://www.egenix.com/): eGenix is a software project, consulting and product company focusing on expert services and professional quality products for companies, Python users and developers. Enjoy, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 25 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2013-03-13: Released eGenix pyOpenSSL 0.13 ... http://egenix.com/go39 ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From vernondcole at gmail.com Tue Mar 26 12:15:57 2013 From: vernondcole at gmail.com (Vernon D. Cole) Date: Tue, 26 Mar 2013 05:15:57 -0600 Subject: [DB-SIG] remote Windows database access tool building Message-ID: Dear group: I am seeking your wisdom and advice. Here is my situation: I am working for a small company (eHealthAfrica.org) who has taken a contract to build a software system to be used in collecting and analyzing data relating to polio vaccination efforts in northern Nigeria. (This area contains the largest remaining pool of wild polio virus in the world. I have always wanted to write software that could change the world, and perhaps this is my chance.) eHa prefers to do things in django and Ubuntu, and I have been collecting the data on that platform and building a PostgreSQL database. Now, the Center for Disease Control wants the data on an SQL Server so that they can analyze it using their existing tools. By great good fortune, I just happen to be the guy who maintains the module which can talk to both databases. It is possible to run a django server on a Windows platform using django-mssql, which uses an old fork of adodbapi internally. I have signed up to help upgrade that package, and the django leadership has made noises that they would welcome the result into the realm of supported third-party packages. One sticky point is that they don't like the fact that adodbapi runs only on Windows. They really want to be able to get to SQL Server from a Linux box, too. There are two open-source tools to do that, but neither one leaves potential users with a warm feeling. Neither has the universal connection capability that ADO offers. I ventured to suggest that a remote ADO proxy server might do the job. The idea is to allow a Python program running on Linux to communicate an ADO request to a Windows box which would do the actual data access. I think I know where, inside of adodbapi, I can inject remote procedure calls (or something similar) to make that happen. 1) Am I out of my mind? 2) I am leaning toward pyzmq (or something else) using 0MQ to talk between the Windows proxy and the client. Is this a good choice of tools? Is there something better I should look at? 3) Will the result still be suitable for inclusion in pywin32, or should this new version strike out as a new, independent fork? -- Vernon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mal at egenix.com Tue Mar 26 12:44:33 2013 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 26 Mar 2013 12:44:33 +0100 Subject: [DB-SIG] remote Windows database access tool building In-Reply-To: References: Message-ID: <51518A21.7040504@egenix.com> On 26.03.2013 12:15, Vernon D. Cole wrote: > Dear group: > > I am seeking your wisdom and advice. > > Here is my situation: I am working for a small company (eHealthAfrica.org) > who has taken a contract to build a software system to be used in > collecting and analyzing data relating to polio vaccination efforts in > northern Nigeria. (This area contains the largest remaining pool of wild > polio virus in the world. I have always wanted to write software that could > change the world, and perhaps this is my chance.) eHa prefers to do things > in django and Ubuntu, and I have been collecting the data on that platform > and building a PostgreSQL database. Now, the Center for Disease Control > wants the data on an SQL Server so that they can analyze it using their > existing tools. > > By great good fortune, I just happen to be the guy who maintains the module > which can talk to both databases. > > It is possible to run a django server on a Windows platform using > django-mssql, which uses an old fork of adodbapi internally. I have signed > up to help upgrade that package, and the django leadership has made noises > that they would welcome the result into the realm of supported third-party > packages. One sticky point is that they don't like the fact that adodbapi > runs only on Windows. They really want to be able to get to SQL Server > from a Linux box, too. There are two open-source tools to do that, but > neither one leaves potential users with a warm feeling. Neither has the > universal connection capability that ADO offers. I ventured to suggest > that a remote ADO proxy server might do the job. The idea is to allow a > Python program running on Linux to communicate an ADO request to a Windows > box which would do the actual data access. I think I know where, inside of > adodbapi, I can inject remote procedure calls (or something similar) to > make that happen. > > 1) Am I out of my mind? > > 2) I am leaning toward pyzmq (or something else) using 0MQ to talk between > the Windows proxy and the client. Is this a good choice of tools? Is there > something better I should look at? > > 3) Will the result still be suitable for inclusion in pywin32, or should > this new version strike out as a new, independent fork? You might want to have a look at our mxODBC Connect product, which was developed for situations like the one you describe: http://www.egenix.com/products/python/mxODBCConnect/ It let's you use the robust drivers for SQL Server directly on the Windows server. The client is Python library with no external dependencies, making setup on the client really easy. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 26 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2013-03-25: Released mxODBC 3.2.2 ... http://egenix.com/go40 2013-03-13: Released eGenix pyOpenSSL 0.13 ... http://egenix.com/go39 2013-04-10: Python Meeting Duesseldorf ... 15 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/