Leslie,

<< I have done some testing too. The major issue with the ARM CPU's is with
unaligned memory access. When accessing memory through pointers you may need
to use the "unaligned" keyword to instruct the compiler to take special care
to read the memory. It effects the perfromance too, but I do not know how
much. >>

Thanks, I'll definitely look out for this.  All of the memory allocation in
EDB is done on at least 8-byte boundaries, so this shouldn't be an issue.
Due to the managed code requirement for .NET, the EDB source code doesn't
use pointers except in a handful of places for purposes of speeding up
native (non-.NET) access to buffers.

<< We need to start to apply the changes in the WinCE client of the program
this month, but a beta version could be good enough for  that.  I guess beta
testing could help you too. First half of August could be good enough for
stable version. >>

Okay.  It will be tight, but I will certainly give it my best shot.

<< I am going to do some testing now with the Windows trial version to make
sure it fits our needs. If there will be no major issues -which I expect -
then  I should be doing some testing with at least the beta WinCe port
because performance and memory usage are big issues with PDA's. If the tests
will  prove what I am hoping for, then you have a new costumer. >>

EDB is pretty light on memory consumption, and the navigational aspects of
EDB are very beneficial for low-power microprocessors that don't handle a
lot SQL compilation and execution very easily.

<< Thank you for the quick reaction. I certanly did not expect it on a
Friday evening. >>

I'm here all the time.  That's what happens when you don't have a life.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

This link might be useful: http://wiki.lazarus.freepascal.org/Windows_CE_Development_Notes
Try to search the page for "unailigned".


"Okay.  It will be tight, but I will certainly give it my best shot."

I would not want to force our shedule on you, but would be happy to try it myself.

"EDB is pretty light on memory consumption, and the navigational aspects of
EDB are very beneficial for low-power microprocessors that don't handle a
lot SQL compilation and execution very easily."

Sounds really promising.


I have signed up  for downloading the latest trial version, but it requires "manual"
approve  from your team. Any chance you can give me the permission? (You can identify my
request by the progman97@mi-net.hu e-mail address. )

Leslie

Tim,

One more peace of information. FPC has three branches, the next stable version will be
2.2.2. You should probably install Lazarus with FPC2.2.2RC1 or FPC2.2.3 from  here:
http://snapshots.lazarus.shikami.org/lazarus/
You will need the "win32" and the "win32 -> arm wince"  installer.



Or you can build  Lazarus/FPC  from the svn version source. Setting up the development
enviroment from the source for the first time may take quite some time,  but keeping
updated should be easier after that.  
There has been some rewrite in the graphic handling lately, which effected the Lazarus IDE
quite badly. If you are experiencing problems you may need to revert to an older SVN
version, or I can send you a few weeks older snapshot installer, which is already not
available.


Leslie

Leslie,

<< This link might be useful:
http://wiki.lazarus.freepascal.org/Windows_CE_Development_Notes Try to
search the page for "unailigned".  >>

Will do, thanks.

<< I would not want to force our shedule on you, but would be happy to try
it myself. >>

Oh no, not at all - I was planning on doing it next anyways.

<< I have signed up  for downloading the latest trial version, but it
requires "manual" approve  from your team. Any chance you can give me the
permission? (You can identify my request by the progman97@mi-net.hu e-mail
address. ) >>

Done.  The login information should be on its way.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Done.  The login information should be on its way."

Delivered. Thank you Tim.

One more potential  issue:  WinCe and Lazarus uses UTF8 encoding and I think FPC still
uses ANSI.

By the way, have you considered supporting UTF8 too?


Leslie

And one more potentaly small one: WinCE does not support relative paths.

Leslie,

<< One more potential  issue:  WinCe and Lazarus uses UTF8 encoding and I
think FPC still uses ANSI. >>

I'm pretty sure that they support widestrings (Unicode):

http://www.freepascal.org/docs-html/ref/refsu11.html

and Windows CE does support Unicode also.

<< By the way, have you considered supporting UTF8 too? >>

No, not really.  4-byte Unicode isn't far off, and UTF8 is a pretty big pain
in the rear to deal with in a database application.

--
Tim Young
Elevate Software
www.elevatesoft.com

Leslie,

<< And one more potentaly small one: WinCE does not support relative paths.
>>

Although relative paths are possible with EDB, we don't encourage their use
for various reasons.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

"<< By the way, have you considered supporting UTF8 too? >>

No, not really.  4-byte Unicode isn't far off, and UTF8 is a pretty big pain
in the rear to deal with in a database application."

I can understand why, even though I have not used UTF8 much myself. In my consideration
the main perfromance bottleneck in database mangement is disk access. UTF8 requires
significantly less IO's when western languagges are used, so I  would expect significant
performance gain there.

Anyhow, you people are running a business here, and I am sure you are making the right
decisions.

Like the WinCE port. I just thought it might be useful trying to help to spot the
potentally problematic areas.

Please let me know if you have made some progress! (Or if you are encountering problems I
might be able to help with.) Also it is imortant for me to know if there is a change in
your timetable.

Warm Regards,
Leslie



   

Leslie,

<< I can understand why, even though I have not used UTF8 much myself. In my
consideration the main perfromance bottleneck in database mangement is disk
access. UTF8 requires significantly less IO's when western languagges are
used, so I would expect significant performance gain there. >>

Usually, the *amount* of I/O is less of an issue than the *number* of I/O
calls.  That's why you see database engines like ElevateDB jumping through
hoops to optimize reads and commits so that they are done in the largest
chunks possible.  They do this through larger block allocations and
read-ahead, and also through optimized writes that try to write out
everything in one large, contiguous chunk.

<< Anyhow, you people are running a business here, and I am sure you are
making the right decisions. >>

Well, in our case you're right, but I wouldn't apply that rule to every
business.

<< Like the WinCE port. I just thought it might be useful trying to help
to spot the potentally problematic areas. >>

Absolutely.  We definitely appreciate any input that you can provide.
There's no such thing as too much information.

<< Please let me know if you have made some progress! (Or if you are
encountering problems I might be able to help with.) Also it is imortant for
me to know if there is a change in your timetable. >>

I've started on it today, and things so far look pretty smooth.  I'll let
everyone know how it progresses here on the newsgroups.

--
Tim Young
Elevate Software
www.elevatesoft.com