i don't know why the project-manager did switch back to 2012 ): on testing & trunk
Because of this i currently didn't merge the fixes to \testing.
I've tested 2044 on Linux32Bit + FPC2.6.0.
Remaining is now a Linux FPC2.7.1. Must i really download Debian, like Michal proposes? Or is there a FPC2.7.1 + Lazarus available for Linux too? I didn't find a compiled package )):
Although I use fresh Lazarus from trunk (I have two svn versions of Lazarus installed actually - fixes branch and trunk), I haven't built fpc myself (and yes, I am afraid that is what you have to do for fpc 2.7), I have only fpc 2.6.0 installed.
Building the compiler is not a trivial task I'm afraid - see: http://www.stack.nl/~marcov/buildfaq.pdf
However, there might be an easier way to build fpc from trunk -- Take a look at fpcup utility by Big Chimp and LudoB. I haven't tested it myself, though.
many thanks for the details. But i used Linux + CodeTyphoon3.0. Now i was able to verify the compilation issue by my selves with FPC2.7.1 and Linux. And Michal is right. The reason was a little bit off i think because the (i was starting from this premise) global define FPC_HAS_BUILTIN_WIDESTR_MANAGER isn't available for linux. Why i don't know but the functions i access are available.
Case closed Rev. 2047 /tesing-7.1 (SVN).
Another thing: This encoding stuff was a little bit complicated and a blind flight for me. But implementing 3 possible ways to get this running for FPC and only one way for Delphi was q question of buhhh ((:. Currently i see no reasons for touching the units again.
Did you notice that in CodeTyphon they trying to crosscompile to jvm-java? Shocked
Nope, i didn't. But i was really surpriced what the hell they can do! A nice workout. But for the first i used it only to see whats going wrong and run my tests on Linux.
-> bussy with oracle. We need imbelievable many functions more to get the first approach with DataSet-Fields running )):
currently i must admit the Oracle stuff becames to complicated. Endless issues are to expect getting the NestedDataSets running. It's a little bit ad hock only read them. But getting a editable approach running is a endless workout. Imagine we need a Orcale-specific TDataSet descendant and a New ResutlSet-Type to support this. I don't wanna say i broke with this approach but yet i say priority low because that means a imbeleavable big workout with again unknown man rows.
Another thing accordingly the SQLite speed issue:
I think you mean open a table with a large list of rows, right?
I started several approaches to get another way running. But all of them fail because the Statment handles need a SQLite-Reset to unlock the Table which is needed to be able to edit the table with another TZQuery for example. I was able to open a table with 300000 rows in less than a second because i did load only the rows you currently can see with the DataSet. But then you're not able to execute any other update on this selected Table. Annoying, really. But that's a proplem of the SQLite protocol which works sequentially. So the reason why SQLite is slow is simlpe: We need to fetch all rows, release the Statment-handle to be sure another statement can edit something there. On the other hand you'll allways get the exception "Database is locked".
I'm sorry again. I do not see a generic way to change this behavior.
