Обсуждение: About wxODBC
Hi, all
The class wxDb has a method: GetCatalog(const wxChar *userID)
We can use it to retrieve tables' info.
But, this method return a pointer to wxDbInf.
The class wxDbInf has some fields:
wxChar catalog[128+1];
wxChar schema[128+1]; // typically means owner of table(s)
int numTables; // How many tables does this datasource have
wxDbTableInf *pTableInf; // Equals a new wxDbTableInf[numTables];
The problem is that the schema field looks wrong.
When there are multiple schemas in corresponding database,
it is the first one's name(alphabetic).
And the class wxDbTableInf don't include schema-name.
Do you know how to get full table list and their schema?
I had tried some wxWidgets methods, did not found.
If it can't, we have to let user input a SQL statement manually.
And under MS-Windows, we can use ODBC API: SQLTables method to do this.
Thanks.
-----------------------------------------------
Quan Zongliang
quanzongliang@gmail.com
CIT Japan: http://www.cit.co.jp
CIT China: http://www.citbj.com.cn
Hi, all I had checked some source of the wxODBC classes. It seems that some code are wrong. So, we have to derive new class from them and rewrite some method. What's your thoughts? These must take more long time. And the work is stopped now, I am studying the Python to read pgLoader source. And more, my boss had given me permission from end of last year to work for freeware in our office if there is not office work need to do. Regards. ----------------------------------------------- Quan Zongliang quanzongliang@gmail.com CIT Japan: http://www.cit.co.jp CIT China: http://www.citbj.com.cn
On Fri, Feb 20, 2009 at 3:03 AM, Quan Zongliang <quanzongliang@gmail.com> wrote: > Hi, all > > I had checked some source of the wxODBC classes. > It seems that some code are wrong. > So, we have to derive new class from them and rewrite some method. > What's your thoughts? > > These must take more long time. Yeuch. I'm still not convinced we want to use wxODBC - it sounds like it's got more issues than we knew about :-(. How much pain would be involved in using ODBC directly? On Windows, everything should always be available, as it should on Mac (which uses iODBC). On Linux we'd need to be able to run regardless of whether iODBC (or unixODBC if we supported that) was installed. > And the work is stopped now, I am studying the Python to read pgLoader source. OK. > And more, my boss had given me permission from end of last year to > work for freeware in our office if there is not office work need to do. Well, that's good for us, but not good for you if there's lot's of spare time! -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
> Yeuch. I'm still not convinced we want to use wxODBC - it sounds like > it's got more issues than we knew about :-(. How much pain would be > involved in using ODBC directly? On Windows, everything should always > be available, as it should on Mac (which uses iODBC). On Linux we'd > need to be able to run regardless of whether iODBC (or unixODBC if we > supported that) was installed. If our code follow the ODBC standard, I think them will works fine. Like the wxWidgets's definition, include corresponding header files for different platform. A new compile option is needed. > Well, that's good for us, but not good for you if there's lot's of spare time! Don't worry about this. It is not because of economy crisis. ^-^ The most of my company's projects is designed in Japan and developed in China. With the low-cost, our business is same as last serial years almost. And in our projects, always use some free frameworks or tools which coded by java. Sometimes them need be modified in order to support Japanese or Chinese. Most was done by me. But I would like to do something with C or C++. So after discussion with my boss, I got permission. ----------------------------------------------- Quan Zongliang quanzongliang@gmail.com CIT Japan: http://www.cit.co.jp CIT China: http://www.citbj.com.cn
On Mon, Feb 23, 2009 at 3:55 AM, Quan Zongliang <quanzongliang@gmail.com> wrote: >> Yeuch. I'm still not convinced we want to use wxODBC - it sounds like >> it's got more issues than we knew about :-(. How much pain would be >> involved in using ODBC directly? On Windows, everything should always >> be available, as it should on Mac (which uses iODBC). On Linux we'd >> need to be able to run regardless of whether iODBC (or unixODBC if we >> supported that) was installed. > If our code follow the ODBC standard, I think them will works fine. > Like the wxWidgets's definition, include corresponding header files for different platform. > > A new compile option is needed. I think this is the way to go. We should probably get it working on Windows first, and then we can work together to get Mac support working (because both of those platforms *always* support ODBC). Then we can figure out how to deal with Linux - it may take some loose binding magic so we can run in the absence of iODBC on that platform. I'm not sure we need to support unixODBC as well. >> Well, that's good for us, but not good for you if there's lot's of spare time! > Don't worry about this. It is not because of economy crisis. ^-^ > The most of my company's projects is designed in Japan and developed in China. > With the low-cost, our business is same as last serial years almost. Thats good :-) > And in our projects, always use some free frameworks or tools which coded by java. > Sometimes them need be modified in order to support Japanese or Chinese. > Most was done by me. > But I would like to do something with C or C++. > So after discussion with my boss, I got permission. Excellent :-D -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
> I think this is the way to go. We should probably get it working on > Windows first, and then we can work together to get Mac support > working (because both of those platforms *always* support ODBC). Then > we can figure out how to deal with Linux - it may take some loose > binding magic so we can run in the absence of iODBC on that platform. > I'm not sure we need to support unixODBC as well. Ok. ----------------------------------------------- Quan Zongliang quanzongliang@gmail.com CIT Japan: http://www.cit.co.jp CIT China: http://www.citbj.com.cn