From ethan at stoneleaf.us Fri May 11 00:38:04 2012 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 10 May 2012 15:38:04 -0700 Subject: [DB-SIG] ANN: dbf version 0.92.002 released Message-ID: <4FAC434C.40304@stoneleaf.us> Available at http://pypi.python.org/pypi/dbf Fixed issue with Memo fields not returning correct unicode data. Updated many docstrings. Nulls now fully supported. Getting closer to a 1.0 (non-beta!) release; working on PEP 8 compliance, index files, and actual documentation. Biggest change ============== records no longer auto-update back to disk; make sure and use record.write_record() if you want the on-disk version of the table updated, or use the new Write generator which calls .write_record() before returning the next record in the table/list/index/whatever. As always, comments and bug-reports appreciated! From eddy at chaos.org.uk Mon May 14 16:33:44 2012 From: eddy at chaos.org.uk (Edward Welbourne) Date: Mon, 14 May 2012 14:33:44 +0000 Subject: [DB-SIG] Getting a list of tables from a database Message-ID: Hi DB-sig, I'm digging data out of my mobile 'phone so that I don't lose it during an upgrade. It turns out to hold my address-book in a sqlite database, so I duly connected to that using the pysqlite2 package; which implements PEP 249 (DB API 2.0) - indeed, the nearest it gets to documentation was something google found me that mentioned it implemented the PEP. (Hint to the maintainer if reading this: the .__doc__ of either pysqlite2 or its .dbapi2 would be a good place to say that, ideally complete with the PEP's URL.) I looked at SQL references and at the PEP but nothing tells me a standardised way to ask a database its list of tables. SQL tutorials seem to assume I created the tables, so obviously know their names; the explorer trying to make sense of a found database isn't considered. It would seem that each database has its own idiosyncratic way of getting such a list, typically be selecting from a special table, whose name varies from database to database, as does the column name for the names of tables. Oracle: SELECT table_name FROM user_tables (or SELECT owner, table_name FROM all_tables, or FROM dba_tables). SQLite: SELECT name FROM sqlite_master WHERE type='table'; Notice the need for a WHERE clause, in this case. MS's SQL server uses meta-table sys.tables, if my googling is accurate, but the source didn't say what column-name to ask for. Most of SQL is sufficiently standardised to permit writing portable code to explore a database - provided access compatible with PEP 249 is available - without need to know details of the SQL implementation; so it would be nice if some future version of the DB API were to specify a standard method, of connection objects, that can be used to obtain the list of tables available via the connection. I can imagine that most of the other information in meta-tables and kindred magic is only actually useful in conjunction with other implementation-specific features of the database, so not worth exposing in a portable form; but having a list of the table-names I can use in plain SQL queries is useful in general, without need for reference to (other) implementation details. A sufficient solution - for the three sample databases for which I found details - would be to provide a string global of the module, implementing the DB API, whose value is an SQL string that can be passed as the command to its .connect(whatever).cursor().execute(command); but I suspect it would make better sense to provide a separate method of connection objects, that simply returns a list of (or iterator over) table names. Eddy. -- Note: I'm not on DB-sig, so please keep me overtly CC'd in replies, if you care whether I see them ! From vernondcole at gmail.com Tue May 15 04:06:12 2012 From: vernondcole at gmail.com (Vernon Cole) Date: Mon, 14 May 2012 20:06:12 -0600 Subject: [DB-SIG] Getting a list of tables from a database In-Reply-To: References: Message-ID: Eddy: As you discovered, every different database system has a unique way of getting a table listing. The problem with attempting to make a uniform tool for doing that at the PEP 249 level, is that some api packages (such as the one I maintain for Microsoft ADO, and anything that does ODBC) may attach to dozens of different engines. Mine will basically hook up to anything _except_ sqlite. I have no idea which engine or engines may show up at the other end. I attempt to let the user determine that by prividing the non-standard attributes connection.dbs_name and connection.dbs_version. (I borrowed the idea from mxodbc.) The most we should hope for at the PEP 249 level would be to have those attributes become part of the standard. I think that it would be wonderful if someone (you could volunteer) were to make a package which does exactly what you suggest. That package would have to determine what the underlying engine is, then give the correct commands. If you write it, I will use it. I'ld even contribute the query for Microsft SQL tables. -- Vernon Cole On Mon, May 14, 2012 at 8:33 AM, Edward Welbourne wrote: > Hi DB-sig, > > I'm digging data out of my mobile 'phone so that I don't lose it during > an upgrade. It turns out to hold my address-book in a sqlite database, > so I duly connected to that using the pysqlite2 package; which > implements PEP 249 (DB API 2.0) - indeed, the nearest it gets to > documentation was something google found me that mentioned it > implemented the PEP. (Hint to the maintainer if reading this: the > .__doc__ of either pysqlite2 or its .dbapi2 would be a good place to say > that, ideally complete with the PEP's URL.) > > I looked at SQL references and at the PEP but nothing tells me a > standardised way to ask a database its list of tables. SQL tutorials > seem to assume I created the tables, so obviously know their names; the > explorer trying to make sense of a found database isn't considered. It > would seem that each database has its own idiosyncratic way of getting > such a list, typically be selecting from a special table, whose name > varies from database to database, as does the column name for the names > of tables. > > Oracle: > SELECT table_name FROM user_tables > (or SELECT owner, table_name FROM all_tables, or FROM dba_tables). > > SQLite: > SELECT name FROM sqlite_master WHERE type='table'; > Notice the need for a WHERE clause, in this case. > > MS's SQL server uses meta-table sys.tables, if my googling is accurate, > but the source didn't say what column-name to ask for. > > Most of SQL is sufficiently standardised to permit writing portable code > to explore a database - provided access compatible with PEP 249 is > available - without need to know details of the SQL implementation; so > it would be nice if some future version of the DB API were to specify a > standard method, of connection objects, that can be used to obtain the > list of tables available via the connection. > > I can imagine that most of the other information in meta-tables and > kindred magic is only actually useful in conjunction with other > implementation-specific features of the database, so not worth exposing > in a portable form; but having a list of the table-names I can use in > plain SQL queries is useful in general, without need for reference to > (other) implementation details. > > A sufficient solution - for the three sample databases for which I found > details - would be to provide a string global of the module, > implementing the DB API, whose value is an SQL string that can be passed > as the command to its .connect(whatever).cursor().execute(command); but > I suspect it would make better sense to provide a separate method of > connection objects, that simply returns a list of (or iterator over) > table names. > > Eddy. > -- > Note: I'm not on DB-sig, so please keep me overtly CC'd in replies, if > you care whether I see them ! > _______________________________________________ > DB-SIG maillist - DB-SIG at python.org > http://mail.python.org/mailman/listinfo/db-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy47 at halfcooked.com Tue May 15 08:23:34 2012 From: andy47 at halfcooked.com (Andy Todd) Date: Tue, 15 May 2012 16:23:34 +1000 Subject: [DB-SIG] Getting a list of tables from a database In-Reply-To: References: Message-ID: <4FB1F666.3030509@halfcooked.com> On 15/05/12 12:06 PM, Vernon Cole wrote: > Eddy: > As you discovered, every different database system has a unique way > of getting a table listing. The problem with attempting to make a > uniform tool for doing that at the PEP 249 level, is that some api > packages (such as the one I maintain for Microsoft ADO, and anything > that does ODBC) may attach to dozens of different engines. Mine will > basically hook up to anything _except_ sqlite. I have no idea which > engine or engines may show up at the other end. I attempt to let the > user determine that by prividing the non-standard attributes > connection.dbs_name and connection.dbs_version. (I borrowed the idea > from mxodbc.) The most we should hope for at the PEP 249 level would be > to have those attributes become part of the standard. > > I think that it would be wonderful if someone (you could volunteer) > were to make a package which does exactly what you suggest. That package > would have to determine what the underlying engine is, then give the > correct commands. If you write it, I will use it. I'ld even contribute > the query for Microsft SQL tables. > -- > Vernon Cole > > On Mon, May 14, 2012 at 8:33 AM, Edward Welbourne > wrote: > > Hi DB-sig, > > I'm digging data out of my mobile 'phone so that I don't lose it during > an upgrade. It turns out to hold my address-book in a sqlite database, > so I duly connected to that using the pysqlite2 package; which > implements PEP 249 (DB API 2.0) - indeed, the nearest it gets to > documentation was something google found me that mentioned it > implemented the PEP. (Hint to the maintainer if reading this: the > .__doc__ of either pysqlite2 or its .dbapi2 would be a good place to say > that, ideally complete with the PEP's URL.) > > I looked at SQL references and at the PEP but nothing tells me a > standardised way to ask a database its list of tables. SQL tutorials > seem to assume I created the tables, so obviously know their names; the > explorer trying to make sense of a found database isn't considered. It > would seem that each database has its own idiosyncratic way of getting > such a list, typically be selecting from a special table, whose name > varies from database to database, as does the column name for the names > of tables. > > Oracle: > SELECT table_name FROM user_tables > (or SELECT owner, table_name FROM all_tables, or FROM dba_tables). > > SQLite: > SELECT name FROM sqlite_master WHERE type='table'; > Notice the need for a WHERE clause, in this case. > > MS's SQL server uses meta-table sys.tables, if my googling is accurate, > but the source didn't say what column-name to ask for. > > Most of SQL is sufficiently standardised to permit writing portable code > to explore a database - provided access compatible with PEP 249 is > available - without need to know details of the SQL implementation; so > it would be nice if some future version of the DB API were to specify a > standard method, of connection objects, that can be used to obtain the > list of tables available via the connection. > > I can imagine that most of the other information in meta-tables and > kindred magic is only actually useful in conjunction with other > implementation-specific features of the database, so not worth exposing > in a portable form; but having a list of the table-names I can use in > plain SQL queries is useful in general, without need for reference to > (other) implementation details. > > A sufficient solution - for the three sample databases for which I found > details - would be to provide a string global of the module, > implementing the DB API, whose value is an SQL string that can be passed > as the command to its .connect(whatever).cursor().execute(command); but > I suspect it would make better sense to provide a separate method of > connection objects, that simply returns a list of (or iterator over) > table names. > > Eddy. > -- > Note: I'm not on DB-sig, so please keep me overtly CC'd in replies, if > you care whether I see them ! This is hard. Gerald [1] attempts to provide a compact but meaningful and consistent data dictionary for a number of backends (currently Oracle, MySQL and Postgres). Patches or suggestions for improvement - including a module for SQLite - are welcome. The industry standard (if such a term can be used) is for relational databases to provide an INFORMATION_SCHEMA [2]. The problem with this is that where it is provided (and AFAIK SQLite doesn't) not all databases are equal (MySQL doesn't provide 'referential_constraints' for instance) and some key pieces of information aren't included. Although to be fair these are usually elements such as tablespace which are implementation specific so wouldn't be expected to be available in 'standard' views. [1] http://halfcooked.com/code/gerald/ [2] https://en.wikipedia.org/wiki/Information_Schema Regards, Andy -- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From mal at egenix.com Tue May 15 08:59:08 2012 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 15 May 2012 08:59:08 +0200 Subject: [DB-SIG] Getting a list of tables from a database In-Reply-To: References: Message-ID: <4FB1FEBC.4000703@egenix.com> Edward Welbourne wrote: > Hi DB-sig, > > I'm digging data out of my mobile 'phone so that I don't lose it during > an upgrade. It turns out to hold my address-book in a sqlite database, > so I duly connected to that using the pysqlite2 package; which > implements PEP 249 (DB API 2.0) - indeed, the nearest it gets to > documentation was something google found me that mentioned it > implemented the PEP. (Hint to the maintainer if reading this: the > .__doc__ of either pysqlite2 or its .dbapi2 would be a good place to say > that, ideally complete with the PEP's URL.) > > I looked at SQL references and at the PEP but nothing tells me a > standardised way to ask a database its list of tables. SQL tutorials > seem to assume I created the tables, so obviously know their names; the > explorer trying to make sense of a found database isn't considered. It > would seem that each database has its own idiosyncratic way of getting > such a list, typically be selecting from a special table, whose name > varies from database to database, as does the column name for the names > of tables. > > Oracle: > SELECT table_name FROM user_tables > (or SELECT owner, table_name FROM all_tables, or FROM dba_tables). > > SQLite: > SELECT name FROM sqlite_master WHERE type='table'; > Notice the need for a WHERE clause, in this case. > > MS's SQL server uses meta-table sys.tables, if my googling is accurate, > but the source didn't say what column-name to ask for. > > Most of SQL is sufficiently standardised to permit writing portable code > to explore a database - provided access compatible with PEP 249 is > available - without need to know details of the SQL implementation; so > it would be nice if some future version of the DB API were to specify a > standard method, of connection objects, that can be used to obtain the > list of tables available via the connection. > > I can imagine that most of the other information in meta-tables and > kindred magic is only actually useful in conjunction with other > implementation-specific features of the database, so not worth exposing > in a portable form; but having a list of the table-names I can use in > plain SQL queries is useful in general, without need for reference to > (other) implementation details. > > A sufficient solution - for the three sample databases for which I found > details - would be to provide a string global of the module, > implementing the DB API, whose value is an SQL string that can be passed > as the command to its .connect(whatever).cursor().execute(command); but > I suspect it would make better sense to provide a separate method of > connection objects, that simply returns a list of (or iterator over) > table names. What you're describing sounds a lot like the catalog methods in the ODBC standard. Those are typically implemented by either having the ODBC drivers implement a set of queries that generate result sets in a predefined format, or by adding views to the database backend which implement them. Sometimes, both methods are used. The application can then call the catalog methods with a set of parameters and the database will run the queries to build the result set with meta data. Even though most databases provide the needed information, I'm not sure whether we should ask database module authors to implement similar catalog methods. The reason is that for some of them, the required information may not be readily available in the database, or may require installing views to allow users without full permissions to retrieve the data from the system tables. We could standardize those methods as optional add-ons to the DB-API specification, though, so that those modules which do want to implement them at least all use the same methods, parameters and result set layouts. If there is interest in this, I'd suggest to follow the ODBC standard for this and use method names derived from the ODBC API names. mxODBC implements these and also documents the result set layouts: http://www.egenix.com/products/python/mxODBC/doc/#_Toc269754615 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 15 2012) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2012-07-02: EuroPython 2012, Florence, Italy 48 days to go 2012-04-26: Released mxODBC 3.1.2 http://egenix.com/go28 2012-04-25: Released eGenix mx Base 3.2.4 http://egenix.com/go27 ::: Try our new 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 Chris.Clark at actian.com Tue May 15 19:21:49 2012 From: Chris.Clark at actian.com (Chris Clark) Date: Tue, 15 May 2012 10:21:49 -0700 Subject: [DB-SIG] Getting a list of tables from a database In-Reply-To: <4FB1FEBC.4000703@egenix.com> References: <4FB1FEBC.4000703@egenix.com> Message-ID: <4FB290AD.9060403@actian.com> On Tuesday 2012-05-15 10:16 (-0700), M.-A. Lemburg wrote: > What you're describing sounds a lot like the catalog methods in > the ODBC standard. > > Those are typically implemented by either > having the ODBC drivers implement a set of queries that generate > result sets in a predefined format, or by adding views to the > database backend which implement them. Sometimes, both methods > are used. > > The application can then call the catalog methods with a > set of parameters and the database will run the queries to > build the result set with meta data. > > Even though most databases provide the needed information, > I'm not sure whether we should ask database module authors > to implement similar catalog methods. The reason is that > for some of them, the required information may not be > readily available in the database, or may require installing > views to allow users without full permissions to retrieve > the data from the system tables. > > We could standardize those methods as optional add-ons to > the DB-API specification, though, so that those modules > which do want to implement them at least all use the > same methods, parameters and result set layouts. > > If there is interest in this, I'd suggest to follow the > ODBC standard for this and use method names derived from > the ODBC API names. mxODBC implements these and also > documents the result set layouts: > > http://www.egenix.com/products/python/mxODBC/doc/#_Toc269754615 I agree with this approach, it should be optional. The original Jython JDBC driver implemented meta data lookup functions with a similar API (JDBC and ODBC are very similar). See http://www.jython.org/archive/21/docs/zxjdbc.html for more details. if you need this today, I'd recommend Vernon's idea, implement a separate package (possibly based on some code from http://halfcooked.com/code/gerald/schema_api.html ) Chris From eddy at opera.com Tue May 15 17:17:53 2012 From: eddy at opera.com (Edward Welbourne) Date: Tue, 15 May 2012 17:17:53 +0200 Subject: [DB-SIG] Getting a list of tables from a database In-Reply-To: (message from Vernon Cole on Mon, 14 May 2012 20:06:12 -0600) Message-ID: Vernon Cole: > The problem with attempting to make a uniform tool for doing that at > the PEP 249 level, is that some api packages (such as the one I > maintain for Microsoft ADO, and anything that does ODBC) may attach to > dozens of different engines. Sounds painful. I'm not a database expert - I've had enough contact with them to understand how useful it is that PEP 249 spares me the details ! - so let me check I understand. ODBC is an abstraction layer between databases, that lets you access diverse databases via a common API, much as PEP 249 does, but at closer-to-SQL level. You appear to be saying its common API doesn't provide a sensible way to ask each of its data-sources for its list of tables - the client of ODBC is spared most of the details of the underlying database, but is still left out to dry where it comes to getting a list of tables. This naturally makes it hard to implement a list of tables in the python interface to ODBC (and similar abstraction layers). Sounds like ODBC isn't quite abstract enough ! ... or have I misunderstood you ? > I attempt to let the user determine that by prividing the non-standard > attributes connection.dbs_name and connection.dbs_version. (I > borrowed the idea from mxodbc.) The most we should hope for at the > PEP 249 level would be to have those attributes become part of the > standard. This simply pushes the problem off onto the client of the module, obliging them to delve into the pecuiarities of each database, which rather works against the idea of having an abstraction layer - although, of course, the abstraction layer saves clients *most* of the need to know details of the underlying system. It's just frustrating to be left with functionality that's naturally part of the abstraction but not practical to include in it - due to an intervening abstraction layer that doesn't bother with the part in question. I think it would be better to specify the list-of-tables as an optional method of connections in the DB API. Those implementations that aren't stuck on the wrong side of an upstream abstraction that lacks the necessary functionality can then support it, which is better than no-one being able to. Marc-Andre Lemburg: > What you're describing sounds a lot like the catalog methods in > the ODBC standard. That all went clear over the top of my head ! As I say above, I'm no expert on databases; I know barely enough to scrape data off my old 'phone before an upgrade, with a lot of help from google ... Eddy. From mike_mp at zzzcomputing.com Wed May 16 19:36:48 2012 From: mike_mp at zzzcomputing.com (Michael Bayer) Date: Wed, 16 May 2012 13:36:48 -0400 Subject: [DB-SIG] Getting a list of tables from a database In-Reply-To: References: Message-ID: On May 14, 2012, at 10:33 AM, Edward Welbourne wrote: > > Most of SQL is sufficiently standardised to permit writing portable code > to explore a database - provided access compatible with PEP 249 is > available - without need to know details of the SQL implementation; so > it would be nice if some future version of the DB API were to specify a > standard method, of connection objects, that can be used to obtain the > list of tables available via the connection. while not part of PEP 249 or probably appropriate as part of the "standard", portable schema information is one of the goals of SQLAlchemy, which it provides via the Inspector interface. For example, the listing of table names in the default schema is as follows: from sqlalchemy import create_engine from sqlalchemy.engine.reflection import Inspector engine = create_engine("mydialect://user:pass at host/dbname") insp = Inspector.from_engine(engine) print insp.get_table_names() SQLAlchemy implements a sizable array of database "dialects", each of which perform the requisite queries to get at various bits of schema detail, including the ability to represent a full series of tables as navigable Python constructs. From phd at phdru.name Fri May 25 21:46:39 2012 From: phd at phdru.name (Oleg Broytman) Date: Fri, 25 May 2012 23:46:39 +0400 Subject: [DB-SIG] SQLObject 1.3.1 Message-ID: <20120525194639.GD20997@iskra.aviel.ru> Hello! I'm pleased to announce version 1.3.1, the first bug-fix release of branch 1.3 of SQLObject. What is SQLObject ================= SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB). Where is SQLObject ================== Site: http://sqlobject.org Development: http://sqlobject.org/devel/ Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: http://pypi.python.org/pypi/SQLObject/1.3.1 News and changes: http://sqlobject.org/News.html What's New ========== * Fixed a minor bug in PostgreSQL introspection: VIEWs don't have PRIMARY KEYs - use sqlmeta.idName as the key. * Fixed a bug in cache handling while unpickling. For a more complete list, please see the news: http://sqlobject.org/News.html Oleg. -- Oleg Broytman http://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From rupinder.mudher at simplyhealth.co.uk Tue May 29 12:15:26 2012 From: rupinder.mudher at simplyhealth.co.uk (Rupinder Mudher) Date: Tue, 29 May 2012 11:15:26 +0100 Subject: [DB-SIG] Query on using cx_Oracle Message-ID: Hi all I am new to using python . I have installed version 2.6 Python within the Ecllipse environment and loaded cx_Oracle as well (from sourceforge website) I run into the following errors when I call cx_Oracle from python. The client version on the machine is Oracle 9.2. Running :- modules help - displays cx_Oracle, however using import cx_Oracle gives following errors:- ['C:\\workspace\\databaseproject\\src', 'C:\\workspace\\databaseproject\\src', 'C:\\Python26\\python26.zip', 'C:\\Python26\\DLLs', 'C:\\Python26\\lib', 'C:\\Python26\\lib\\plat-win', 'C:\\Python26\\lib\\lib-tk', 'C:\\Python26', 'C:\\Python26\\lib\\site-packages'] Traceback (most recent call last): File "C:\workspace\databaseproject\src\datbaasemodule.py", line 13, in import cx_Oracle ImportError: DLL load failed: The specified procedure could not be found. Any help would be appreciated. Rupinder Mudher Oracle Database and Middleware Specialist Simplyhealth Anton House, Chantry Street, Andover, Hants, SP10 1DE t: 01264 342643 ext:2990 e: rupinder.mudher at simplyhealth.co.uk w: www.simplyhealth.co.uk The content of this email is private. If you think you may have received it by mistake, please notify Simplyhealth immediately by telephoning us on 0845 075 2020, or emailing network.administrator at simplyhealth.co.uk then destroy the original email without using, copying or distributing it. The content is non binding and is subject to contract unless specifically stated otherwise. Any views expressed are not necessarily those of Simplyhealth. Simplyhealth is a trading name of Simplyhealth Access, Simplyhealth Administration Services Limited and Totally Active Limited, all are subsidiaries of Simplyhealth Group Limited, registered in England and Wales No. 5445654. Simplyhealth Access is registered in England and Wales, No.183035 and is authorised and regulated by the Financial Services Authority. Simplyhealth Administration Services Limited is registered in England and Wales, No. 5961472 and is an appointed representative of Simplyhealth Access. Totally Active Limited is registered in England and Wales, No. 4932453 Registered office for all companies is Hambleden House, Waterloo Court, Andover, Hampshire SP10 1LQ. Calls may be recorded and monitored for training and quality assurance purposes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From haraldarminmassa at gmail.com Tue May 29 12:57:20 2012 From: haraldarminmassa at gmail.com (Harald Armin Massa[legacy]) Date: Tue, 29 May 2012 12:57:20 +0200 Subject: [DB-SIG] Query on using cx_Oracle In-Reply-To: References: Message-ID: Hello Rupinder, > Traceback (most recent call last): > ? File "C:\workspace\databaseproject\src\datbaasemodule.py", line 13, in > > ??? import cx_Oracle > ImportError: DLL load failed: The specified procedure could not be found. most likely: the Oracle-OCI-Librarys are not in your path. Make sure oci.dll and the other megabytes or Oracles Client libs are within your system path. Best wishes Harald -- LightningTalkMan a brand of GHUM GmbH Spielberger Stra?e 49 70435 Stuttgart 0173/9409607 From haraldarminmassa at gmail.com Tue May 29 13:01:04 2012 From: haraldarminmassa at gmail.com (Harald Armin Massa[legacy]) Date: Tue, 29 May 2012 13:01:04 +0200 Subject: [DB-SIG] Query on using cx_Oracle In-Reply-To: References: Message-ID: You do need those libraries in the WINDOWS Path of your environment. most robust version: have it in the system path. Google "change windows system path" for your specific windows version (my computer, extended, environment-variables... but Microsoft optimzes the placement from version to vversion. Harald 2012/5/29 Rupinder Mudher : > Hello Harald > > Thanks for replying - ? I have checked and located oci.dll in oracle/ora92. > How do I get these in the PATH - using windows - so I add an Env. variable? > > Regards > > -----Original Message----- > From: chef at ghum.de [mailto:chef at ghum.de] On Behalf Of Harald Armin Massa[legacy] > Sent: 29 May 2012 11:57 > To: Rupinder Mudher > Cc: db-sig at python.org > Subject: Re: [DB-SIG] Query on using cx_Oracle > > Hello Rupinder, > >> Traceback (most recent call last): >> ? File "C:\workspace\databaseproject\src\datbaasemodule.py", line 13, >> in >> ??? import cx_Oracle >> ImportError: DLL load failed: The specified procedure could not be found. > > most likely: the Oracle-OCI-Librarys are not in your path. Make sure oci.dll and the other megabytes or Oracles Client libs are within your system path. > > Best wishes > > Harald > > > > -- > LightningTalkMan > a brand of GHUM GmbH > Spielberger Stra?e 49 > 70435 Stuttgart > 0173/9409607 > The content of this email is private. If you think you may have received it by mistake, please notify Simplyhealth immediately by telephoning us on > 0845 075 2020, or emailing network.administrator at simplyhealth.co.uk then destroy the original email without using, copying or distributing it. > > The content is non binding and is subject to contract unless specifically stated otherwise. Any views expressed are not necessarily those of Simplyhealth. > > Simplyhealth is a trading name of Simplyhealth Access, Simplyhealth Administration Services Limited and Totally Active Limited, all are subsidiaries of > Simplyhealth Group Limited, registered in England and Wales No. 5445654. Simplyhealth Access is registered in England and Wales, No.183035 and is > authorised and regulated by the Financial Services Authority. Simplyhealth Administration Services Limited is registered in England and Wales, No. 5961472 > and is an appointed representative of Simplyhealth Access. > > Totally Active Limited is registered in England and Wales, No. 4932453 > > Registered office for all companies is Hambleden House, Waterloo Court, Andover, Hampshire SP10 1LQ. > > Calls may be recorded and monitored for training and quality assurance purposes. -- LightningTalkMan a brand of GHUM GmbH Spielberger Stra?e 49 70435 Stuttgart 0173/9409607 From rupinder.mudher at simplyhealth.co.uk Tue May 29 12:58:56 2012 From: rupinder.mudher at simplyhealth.co.uk (Rupinder Mudher) Date: Tue, 29 May 2012 11:58:56 +0100 Subject: [DB-SIG] Query on using cx_Oracle References: Message-ID: Hello Harald Thanks for replying - I have checked and located oci.dll in oracle/ora92. How do I get these in the PATH - using windows - so I add an Env. variable? Regards -----Original Message----- From: chef at ghum.de [mailto:chef at ghum.de] On Behalf Of Harald Armin Massa[legacy] Sent: 29 May 2012 11:57 To: Rupinder Mudher Cc: db-sig at python.org Subject: Re: [DB-SIG] Query on using cx_Oracle Hello Rupinder, > Traceback (most recent call last): > ? File "C:\workspace\databaseproject\src\datbaasemodule.py", line 13, > in > ??? import cx_Oracle > ImportError: DLL load failed: The specified procedure could not be found. most likely: the Oracle-OCI-Librarys are not in your path. Make sure oci.dll and the other megabytes or Oracles Client libs are within your system path. Best wishes Harald -- LightningTalkMan a brand of GHUM GmbH Spielberger Stra?e 49 70435 Stuttgart 0173/9409607 The content of this email is private. If you think you may have received it by mistake, please notify Simplyhealth immediately by telephoning us on 0845 075 2020, or emailing network.administrator at simplyhealth.co.uk then destroy the original email without using, copying or distributing it. The content is non binding and is subject to contract unless specifically stated otherwise. Any views expressed are not necessarily those of Simplyhealth. Simplyhealth is a trading name of Simplyhealth Access, Simplyhealth Administration Services Limited and Totally Active Limited, all are subsidiaries of Simplyhealth Group Limited, registered in England and Wales No. 5445654. Simplyhealth Access is registered in England and Wales, No.183035 and is authorised and regulated by the Financial Services Authority. Simplyhealth Administration Services Limited is registered in England and Wales, No. 5961472 and is an appointed representative of Simplyhealth Access. Totally Active Limited is registered in England and Wales, No. 4932453 Registered office for all companies is Hambleden House, Waterloo Court, Andover, Hampshire SP10 1LQ. Calls may be recorded and monitored for training and quality assurance purposes. From anthony.tuininga at gmail.com Tue May 29 15:35:31 2012 From: anthony.tuininga at gmail.com (Anthony Tuininga) Date: Tue, 29 May 2012 07:35:31 -0600 Subject: [DB-SIG] Query on using cx_Oracle In-Reply-To: References: Message-ID: Hi, In this case I believe you are using too old a version of Oracle. The later versions of cx_Oracle do not support Oracle 9i as Oracle has stopped supporting that version a long time ago and I no longer have access to that version. I would suggest bumping your Oracle client to Oracle 10 or 11 if at all possible. If not possible, you will need to use an older version of cx_Oracle which still supported Oracle 9. Anthony On Tue, May 29, 2012 at 5:01 AM, Harald Armin Massa[legacy] wrote: > You do need those libraries in the WINDOWS Path of your environment. > most robust version: have it in the system path. Google "change > windows system path" for your specific windows version (my computer, > extended, environment-variables... but Microsoft ?optimzes the > placement from version to vversion. > > Harald > > 2012/5/29 Rupinder Mudher : >> Hello Harald >> >> Thanks for replying - ? I have checked and located oci.dll in oracle/ora92. >> How do I get these in the PATH - using windows - so I add an Env. variable? >> >> Regards >> >> -----Original Message----- >> From: chef at ghum.de [mailto:chef at ghum.de] On Behalf Of Harald Armin Massa[legacy] >> Sent: 29 May 2012 11:57 >> To: Rupinder Mudher >> Cc: db-sig at python.org >> Subject: Re: [DB-SIG] Query on using cx_Oracle >> >> Hello Rupinder, >> >>> Traceback (most recent call last): >>> ? File "C:\workspace\databaseproject\src\datbaasemodule.py", line 13, >>> in >>> ??? import cx_Oracle >>> ImportError: DLL load failed: The specified procedure could not be found. >> >> most likely: the Oracle-OCI-Librarys are not in your path. Make sure oci.dll and the other megabytes or Oracles Client libs are within your system path. >> >> Best wishes >> >> Harald >> >> >> >> -- >> LightningTalkMan >> a brand of GHUM GmbH >> Spielberger Stra?e 49 >> 70435 Stuttgart >> 0173/9409607 >> The content of this email is private. If you think you may have received it by mistake, please notify Simplyhealth immediately by telephoning us on >> 0845 075 2020, or emailing network.administrator at simplyhealth.co.uk then destroy the original email without using, copying or distributing it. >> >> The content is non binding and is subject to contract unless specifically stated otherwise. Any views expressed are not necessarily those of Simplyhealth. >> >> Simplyhealth is a trading name of Simplyhealth Access, Simplyhealth Administration Services Limited and Totally Active Limited, all are subsidiaries of >> Simplyhealth Group Limited, registered in England and Wales No. 5445654. Simplyhealth Access is registered in England and Wales, No.183035 and is >> authorised and regulated by the Financial Services Authority. Simplyhealth Administration Services Limited is registered in England and Wales, No. 5961472 >> and is an appointed representative of Simplyhealth Access. >> >> Totally Active Limited is registered in England and Wales, No. 4932453 >> >> Registered office for all companies is Hambleden House, Waterloo Court, Andover, Hampshire SP10 1LQ. >> >> Calls may be recorded and monitored for training and quality assurance purposes. > > > > -- > LightningTalkMan > a brand of GHUM GmbH > Spielberger Stra?e 49 > 70435 Stuttgart > 0173/9409607 > _______________________________________________ > DB-SIG maillist ?- ?DB-SIG at python.org > http://mail.python.org/mailman/listinfo/db-sig From rupinder.mudher at simplyhealth.co.uk Wed May 30 16:27:17 2012 From: rupinder.mudher at simplyhealth.co.uk (Rupinder Mudher) Date: Wed, 30 May 2012 15:27:17 +0100 Subject: [DB-SIG] Query on using cx_Oracle References: Message-ID: Hi all Thanks for these replies - I have installed 10gclient and this appears to have resolved The issues Rupinder -----Original Message----- From: Anthony Tuininga [mailto:anthony.tuininga at gmail.com] Sent: 29 May 2012 14:36 To: Harald Armin Massa[legacy] Cc: Rupinder Mudher; db-sig at python.org Subject: Re: [DB-SIG] Query on using cx_Oracle Hi, In this case I believe you are using too old a version of Oracle. The later versions of cx_Oracle do not support Oracle 9i as Oracle has stopped supporting that version a long time ago and I no longer have access to that version. I would suggest bumping your Oracle client to Oracle 10 or 11 if at all possible. If not possible, you will need to use an older version of cx_Oracle which still supported Oracle 9. Anthony On Tue, May 29, 2012 at 5:01 AM, Harald Armin Massa[legacy] wrote: > You do need those libraries in the WINDOWS Path of your environment. > most robust version: have it in the system path. Google "change > windows system path" for your specific windows version (my computer, > extended, environment-variables... but Microsoft ?optimzes the > placement from version to vversion. > > Harald > > 2012/5/29 Rupinder Mudher : >> Hello Harald >> >> Thanks for replying - ? I have checked and located oci.dll in oracle/ora92. >> How do I get these in the PATH - using windows - so I add an Env. variable? >> >> Regards >> >> -----Original Message----- >> From: chef at ghum.de [mailto:chef at ghum.de] On Behalf Of Harald Armin >> Massa[legacy] >> Sent: 29 May 2012 11:57 >> To: Rupinder Mudher >> Cc: db-sig at python.org >> Subject: Re: [DB-SIG] Query on using cx_Oracle >> >> Hello Rupinder, >> >>> Traceback (most recent call last): >>> ? File "C:\workspace\databaseproject\src\datbaasemodule.py", line >>> 13, in >>> ??? import cx_Oracle >>> ImportError: DLL load failed: The specified procedure could not be found. >> >> most likely: the Oracle-OCI-Librarys are not in your path. Make sure oci.dll and the other megabytes or Oracles Client libs are within your system path. >> >> Best wishes >> >> Harald >> >> >> >> -- >> LightningTalkMan >> a brand of GHUM GmbH >> Spielberger Stra?e 49 >> 70435 Stuttgart >> 0173/9409607 >> The content of this email is private. If you think you may have >> received it by mistake, please notify Simplyhealth immediately by >> telephoning us on >> 0845 075 2020, or emailing network.administrator at simplyhealth.co.uk then destroy the original email without using, copying or distributing it. >> >> The content is non binding and is subject to contract unless specifically stated otherwise. Any views expressed are not necessarily those of Simplyhealth. >> >> Simplyhealth is a trading name of Simplyhealth Access, Simplyhealth >> Administration Services Limited and Totally Active Limited, all are >> subsidiaries of Simplyhealth Group Limited, registered in England and >> Wales No. 5445654. Simplyhealth Access is registered in England and Wales, No.183035 and is authorised and regulated by the Financial Services Authority. Simplyhealth Administration Services Limited is registered in England and Wales, No. 5961472 and is an appointed representative of Simplyhealth Access. >> >> Totally Active Limited is registered in England and Wales, No. >> 4932453 >> >> Registered office for all companies is Hambleden House, Waterloo Court, Andover, Hampshire SP10 1LQ. >> >> Calls may be recorded and monitored for training and quality assurance purposes. > > > > -- > LightningTalkMan > a brand of GHUM GmbH > Spielberger Stra?e 49 > 70435 Stuttgart > 0173/9409607 > _______________________________________________ > DB-SIG maillist ?- ?DB-SIG at python.org > http://mail.python.org/mailman/listinfo/db-sig