Hi all,

I just knew recently that Midlet Pascal went open source, through FPC wiki. Quite a good news, IMO. Since it's now open source, is it possible to start working on java byte code generator in FPC based on Midlet Pascal code? This will help FPC targetting mobile devices that only support java application such as Blackberry. Well, I almost know nothing about compiler development, so I just hope it'd be possible someday through the help of Midlet Pascal code.

You'll have to do more than just generate bytecode. You'll need a complete new RTL for that.

Michael.

Generating java is not the real problem, the point is simple that a lot modern OOP language concepts cannot be mapped to java bytecode. An FPC for Java bytecode would be even more cripple than Delphi .Net was.

Florian Klaempfl wrote

Generating java is not the real problem, the point is simple that a lot modern OOP language concepts cannot be mapped to java bytecode. An FPC for Java bytecode would be even more cripple than Delphi .Net was.

Could you give an example?

I wrote a simple procedural Pascal compiler to Java assembler (bytecode via jasmin) and I had no problems mapping the features.

thanks,

I'm trying to develop an application on windows mobile with lazarus/free pascal.
I need SQL server embedded on it to manage a lot of data.

SQLite3 is the only solution available?

I CAN'T find information anywhere... some idea?

Codebue Fabio

Bee Jay wrote

I just knew recently that Midlet Pascal went open source, through FPC wiki.

Could you point to the actually opened midlet Source?

thanks,
dmitry

dmitry boyarintsev wrote

Could you point to the actually opened midlet Source?

http://midletpascal.svn.sourceforge.net/viewvc/midletpascal/

I found this when I contacted the authors of Midlet Pascal and they replied saying that it was given to a group of developers which is converting it from C++ to Delphi. But we have still to see if it will actually develop, but this is surely better then how it was before, as a dead project.

That's very nice, thanks! There have been some talks about Midlet going open source a few months earlier. But since there were no sources it really looked like fake.

Anyway. Even if there's no point in uniting two projects (Midlet and FPC) together, it could be useful to add support for Midlet compiler (there's command-line tool now) in Lazarus.

thanks,
dmitry

You also have Firebird Embeeded and MySQL Embedded (I really dislike MySQL) afaik.

Ido

http://ik.homelinux.org/

On Wed, Dec 16, 2009 at 4:53 PM, Codebue Fabio - P-Soft <

What about data encryption? Is anyone of those providing it ?

Thanks!

R#

2009/12/16 ik :

I use firebird embedded. Fast, reliable, easily installed and much more powerful as sqlite.

Michael.

Michael Van Canneyt wrote

I use firebird embedded. Fast, reliable, easily installed and much more powerful as sqlite.

What is required to use firebird embedded? I know about it, but never looking into it.

We have an application we need to distribute with minimal install and thought of firebird embedded, but I haven't had a chance to read up on it. Any pointers or URL's, wiki pages I can look at?

Regards,
- Graeme -

You need to bind the embedded API for it, and the rest is the same. You act like it's a server.
I haven't done it myself, only read about it in the Firebird's source documentation :)

Ido

http://ik.homelinux.org/

ik wrote

You need to bind the embedded API for it, and the rest is the same. You act like it's a server. I haven't done it myself, only read about it in the Firebird's source documentation :)

All it takes (if you use sqldb) is 1 statement in a unit initialization or program startup code:

uses ibase60dyn; // must be there
Begin
   UseEmbeddedFirebird:=True;

That's it.

Michael.

Roberto Padovani wrote

What about data encryption? Is anyone of those providing it ?

Firebird definitely not.
Personally, I don't think that this is the task of a database engine...

Michael.

Thanks Michael. Any thoughts on a tiOPF patch for the SqlDB persistence layer? ;-)

Regards,
- Graeme -

And what should it do according to you ?

IMHO tiOPF kicks in too late; the layer is loaded only once, at program startup.

Michael.

Michael Van Canneyt wrote

And what should it do according to you ? IMHO tiOPF kicks in too late; the layer is loaded only once, at program startup.

Exactly why I'm asking your? :-) Can the initialization code in SqlDB (firebird embedded) not be delayed or overridden slightly later - after application startup? Note: I haven't tried to use Firebird Embedded yet - so just thinking out loudly.

If push comes to shove, I can always hard-code our "lightweight" apps to use SqlDB Embedded like you showed before, but I would prefer to keep it flexible via compiler defines - like the way persistence layers are toggled in tiOPF.

Regards,
- Graeme -

I don't see the benefit in that. Compiler defines are evil, no need to promote them.

You can perfectly create a descendent of the existing tiOPF DB connection, which, when created, sets the variable if the library was not yet loaded. In effect, this should do the same as what I did PROVIDED no other code attempts to use the sqldb layer.

If you then register this new connection as firebird-embedded, then you have the choice. No compiler defines needed, and you have the choice.

(Note that it is impossible to mix the two, but that is a firebird limitation).

Michael.

2009/12/17 Michael Van Canneyt :

I don't see the benefit in that. Compiler defines are evil, no need to promote them.

The compiler defines for linking persistence layers are limited to one unit out of about three hundred units - no compiler defines are in your actual project code, only in the Compiler Options dialog which then applies to the whole project. So that's not really promoting them.

You can perfectly create a descendent of the existing tiOPF DB connection, which, when created, sets the variable if the library was not yet loaded. In

This is what I meant - I'll take a look closer at the time when we actually need embedded firebird support.

(Note that it is impossible to mix the two, but that is a firebird limitation).

No, I was going to use one or the other, not both firebird connection methods.

I think you talk about Firebird embedded version 1.0, SQlite3 best than it I have Point of Sale application use Firebird 2.1 in desktop PC and Sqlite3 in Wince, the same project with same SQL statements (with a little directive for special queries).

Hello FPC-Pascal,

Tuesday, December 22, 2009, 12:55:07 AM, you wrote:

ZD> I think you talk about Firebird embedded version 1.0, SQlite3 best than it ZD> I have Point of Sale application use Firebird 2.1 in desktop PC and ZD> Sqlite3 in Wince, the same project with same SQL statements (with a ZD> little directive for special queries).

SQLite is faster than Firebird, but take care that SQLite does not enforce foreign keys, so data integrity must be handled by the programmer "manually".

About the "sqlite is faster":

This depends highly on the kind of queries you are using.

In my tests, sqlite was significantly slower than firebird. I compared speeds of 4 different embedded engines, and sqlite was definitely not the fastest one.

Secondly, I would never recommend sqlite for use with Pascal applications, since sqlite does not even enforce the data to be of the correct type, which creates problems if a field of type INT contains e.g. textual data, causing a pascal application to crash.

(last time I checked, they called this "a feature")

Michael.

Not anymore. See http://www.sqlite.org/releaselog/3_6_19.html

Luiz

Hello FPC-Pascal,

you wrote

> SQLite is faster than Firebird, but take care that SQLite does not > enforce foreign keys, so data integrity must be handled by the > programmer "manually".

MVC> About the "sqlite is faster":
MVC> This depends highly on the kind of queries you are using. MVC> In my tests, sqlite was significantly slower than firebird. I compared MVC> speeds of 4 different embedded engines, and sqlite was definitely not MVC> the fastest one.

SQLite is faster in "simple" queries and in exchange with used memory etc. For serious projects with important data it has many deficiences.

MVC> Secondly, I would never recommend sqlite for use with Pascal applications, MVC> since sqlite does not even enforce the data to be of the correct type, which MVC> creates problems if a field of type INT contains e.g. textual data, causing MVC> a pascal application to crash.
MVC> (last time I checked, they called this "a feature")

Yes :) As far as I know, everything is a "text" field.

Can you provide such tests?
Sqlite, due to it's nature (small), is know to have a query optimizer less powerful than other (bigger) RDMS. Most of the time those sql can be manually optimized. Anyway recent versions have improved performance.

It's true if trying to load a data file created outside of the pascal application. Databases created and handled by TDataset descendants (Zeos, TSqlite3Dataset, Sqldb) has no such problems.

(last time I checked, they called this "a feature")

One point not cited in thread was the availability of Firebird embedded that AFAIK is only for Windows.

Not to say that sqlite is probably the most used embedded database: http://www.sqlite.org/mostdeployed.html

Luiz

Yes.

Sqlite, due to it's nature (small), is know to have a query optimizer less powerful than other (bigger) RDMS. Most of the time those sql can be manually optimized. Anyway recent versions have improved performance.

That is good to hear!

That doesn't matter.
You cannot be sure about the data you get, that is the point. You don't know what the user will do to the database file.

I can tell you strange stories of databases which were accessible to users. A helpdesk nightmare :-)

This is not correct. It works perfectly on linux as well, and mac also. I use it on Linux.

Not to say that sqlite is probably the most used embedded database: http://www.sqlite.org/mostdeployed.html

It doesn't take away the fact that I do not consider it suitable for use with pascal. PHP, Java: there it probably doesn't matter, since they use dynamically typed data. But pascal is strongly typed at compile time, and if the engine doesn't guarantee that an INT field contains really an INT, then it's out in my book.

But each should weigh the pros and cons; In my opinion, sqlite is off, but every developer should consider what is important for him.

Michael.

JoshyFun wrote

etc. For serious projects with important data it has many deficiences.

I thought all data should be treated as important - otherwise why bother saving it. :-)

Regards,
- Graeme -

Hello FPC-Pascal,

Tuesday, December 22, 2009, 3:18:27 PM, you wrote:

GG> JoshyFun wrote

> etc. For serious projects with important data it has many deficiences.

GG> I thought all data should be treated as important - otherwise why bother GG> saving it. :-)

Check your temp folder :)

That data is important, at least at one point it was, but no longer, thats what it was saved in the first place.

Ido

Hello FPC-Pascal,

you wrote

> GG> I thought all data should be treated as important - otherwise why > bother > GG> saving it. :-) > Check your temp folder :)

i> That data is important, at least at one point it was, but no longer, thats i> what it was saved in the first place.

Please check the ":)" smiley at the end...

En/na JoshyFun ha escrit:

SQLite is faster than Firebird, but take care that SQLite does not enforce foreign keys, so data integrity must be handled by the programmer "manually".

It does, since version 3.6.19 (released in October). Before that you could enforce foreign keys using triggers, and the triggers could be autogenerated by the .genfkey command.

Bye