Sorry for delay. I have a lot of work. I didn't tested it but I downloaded it and looked in source code and it seems to be fine. But I'm not 100% sure until I try it. I'll test it these days.
All the best,
Damir
DatabaseLayer-devel
I've implemented a couple more of your suggestions.
1) DatabaseResultSet fields can now be retrieved by index rather than name.
2) FirebirdDatabaseLayer now allows for using Firebird Roles when connecting to the database.
These changes are only in CVS so far. The next thing that I'd like to add is the DatabaseMetaData and ResultSetMetaData classes that have been requested.
1) DatabaseResultSet fields can now be retrieved by index rather than name.
2) FirebirdDatabaseLayer now allows for using Firebird Roles when connecting to the database.
These changes are only in CVS so far. The next thing that I'd like to add is the DatabaseMetaData and ResultSetMetaData classes that have been requested.
-
- Super wx Problem Solver
- Posts: 424
- Joined: Tue Jul 12, 2005 8:44 pm
- Location: Alabama, USA
That's good. I haven't required that yet, but it's a good option to have.jb_coder wrote:I've implemented a couple more of your suggestions.
1) DatabaseResultSet fields can now be retrieved by index rather than name.
I also added support for using roles in Firebird but hadn't uploaded it to CVS because I hadn't had time to test it thoroughly. I'll look over your code and see how it works.jb_coder wrote:2) FirebirdDatabaseLayer now allows for using Firebird Roles when connecting to the database.
I've also made a few other changes that I can try to merge with your code.
<UL><LI>I wrote a new ParseQueries routine because I ran into problems when the query contained a semi-colon. The current routine simply splits the query at any semi-colon whether or not it's inside the statement. My routine checks to see if the semi-colon is within the quote marks. I imagine this should be fixed for all databases.</LI>
<LI>I also made a modification so that aliases could be used in SQL queries. It's simply a matter of assigning the field name in the map using pVar->aliasname rather than pVar->sqlname.</LI>
<LI>There are some problems I noticed as well when errors occur in the FirebirdDatabaseLayer::RunQueryWithResults() function. I believe the quickie transaction should first be rolled back before an exception is thrown. This will allow the database to be closed rather than recieving additional errors about transactions that are in progress.</LI></UL>
I also have a semi-working version of an odbc databaselayer library. It still needs some work and testing, but most of the general functionality is there. I guess I need to get the latest CVS and make sure all of my modifications work with your updates.
-Scott
wxMSW 2.6.2, VS 2002, 2003 and 2005, Code::Blocks and mingw, Windows XP Pro
Wow! You've been really busy! Sorry that I didn't coordinate my changes. I was just happy to be coding on DatabaseLayer again after a month or so off from it.
The DatabaseLayer class itself could probably contain the ParseQueries functionality rather than having all the derived classes duplicate the code. I've been thinking about that for a while, but haven't changed any code for it.
Looking at the code, I think that the reason for not rolling back the transaction may have been concerns that the rollback would throw an exception and the original error code would be lost. This can probably be avoided though.
For ODBC, what would you recommend for an ODBC layer on Linux? I'll probably just go with whatever SuSE provides RPMs for, but I can try a specific library instead if that would be better.
The DatabaseLayer class itself could probably contain the ParseQueries functionality rather than having all the derived classes duplicate the code. I've been thinking about that for a while, but haven't changed any code for it.
Looking at the code, I think that the reason for not rolling back the transaction may have been concerns that the rollback would throw an exception and the original error code would be lost. This can probably be avoided though.
For ODBC, what would you recommend for an ODBC layer on Linux? I'll probably just go with whatever SuSE provides RPMs for, but I can try a specific library instead if that would be better.
-
- Super wx Problem Solver
- Posts: 424
- Joined: Tue Jul 12, 2005 8:44 pm
- Location: Alabama, USA
I have a couple projects that are using Firebird, so that gave me an excuse to work on the databaselayer. I also had to move some data from an Access database, so that's when I finished up some of the ODBC stuff.jb_coder wrote:Wow! You've been really busy! Sorry that I didn't coordinate my changes. I was just happy to be coding on DatabaseLayer again after a month or so off from it.
I noticed that all the code was the same for all of the ParseQueries() routines. I don't know of any reason that it would need to be modified, but it could always be a virtual function with a single default implementation. Then a class could override it if necessary.jb_coder wrote:The DatabaseLayer class itself could probably contain the ParseQueries functionality rather than having all the derived classes duplicate the code. I've been thinking about that for a while, but haven't changed any code for it.
I noticed that the InterpretErrorCodes() function needs to be called before attempting to rollback the transaction so that the original error code isn't lost. We just have to work around any additional errors occuring with the rollback.jb_coder wrote:Looking at the code, I think that the reason for not rolling back the transaction may have been concerns that the rollback would throw an exception and the original error code would be lost. This can probably be avoided though.
Well, I've never really used ODBC on Linux before. I just recently setup Ubuntu on my desktop at home, so hopefully I'll get around to trying it soon. For now I've just been trying to get things working on Windows, which hasn't been extremely easy. I'm sure there are some things about the API that I don't fully understand and have added code to work around certain problems. Of course, most of these could probably be solved with a little more research.jb_coder wrote:For ODBC, what would you recommend for an ODBC layer on Linux? I'll probably just go with whatever SuSE provides RPMs for, but I can try a specific library instead if that would be better.
I just downloaded the latest CVS code, so I'll try to merge the changes I'm certain are working and add the initial ODBC code. However, there may be some drastic changes required with ODBC support to get everything working correctly.
-Scott
wxMSW 2.6.2, VS 2002, 2003 and 2005, Code::Blocks and mingw, Windows XP Pro