xsharp.eu

Hi Wolgang
what i see is, that dbf as a database is good enough for a companie with 10 people. but why not a example on sql. i never used sql and i had also never problems with dbf. so i am honest i have no experiance. if u do it with dbf all the things you need is in X# . with sql u need a 3party product. and i allways had trouble after some years with 3party things.
about window form. realy i dont know, what i see is, that in some (older?) apps the windows are normal and the icons close to unvisible.
the ssatutor from vo was for me the entry point for vo after clipper.

Horst

Hi Horst,
personally I see problems with DBF starting from 5 concurrent users.
And I have customers with less than 5 concurrent users that are using filters massively and therefore DBF is not more a good choice.
DBF is becoming not more adeguate because Microsoft in search of performance does much more client side caching leading to more data corruption, and on the other side user expectations have changed over the years.
10 or 15 years ago an incremental search was a really good thing, but these days people seems to use filters, filters and filters, and that pushes DBF data to limits.
I agree that 3rd party software over the years tends to be problematic, but I have some projects with Oracle, MySQL and MS SQL databases that are living for much more than 10 years.
Wolfgang

Hi Horst,

There's nothing wrong with using different dialects than Core. Personally I prefer the VO dialect, because it supports very helpful/powerful to me syntax, like being able to use both single and double quotes for string delimiters. The core dialect is closer to that of c#, but that does not make any better or worse. It's up to everybody to decide what suits them best.

Hi Horst,
let me adding something to what Chris said about dialects: using the Core dialect may give you faster and better applications, but you will need more code because you loose weak typing and things like untyped arrays.
I'm writing much Core dialect code, but I'm not completely happy with it - using the VO dialect programming is faster.
Wolfgang

Hi Wolfgang,

You do not get faster and better applications by using Core dialect and slower if you use other dialects, this only depends on what code you write. If you still use Lists and .Net collections in VO dialect, you will get exactly the same performance as you would have using them in Core.

Hi Chris,
you are right, but I don't meant that.
In the VO dialect you are allowed to use untyped arrays - in Core dialect you need to use lists.
In the VO dialect you are allowed to write "dirty" code - the Core dialect does not permit that.
In untyped arrays you can change them as you loop through them - with collections this is not so easy, unfortunately.
Wolfgang

Hi Wolfgang,

Yeah, in this sense I agree!

Chris, Wolfgang
i like also the VO dialect. and Wolfgang i love the clipper array handling.
but whats about the x86 switch ? its create's 32bit apps only ?
so one day ..
Horst

Horst,
The X# Runtime can run in both X86 and X64 mode.
However the VO GUI classes and some other parts of the VO SDK classes were never designed to be used in x64 mode: they contain lots of "dangerous" casts between 32 bit numbers and pointers (which are 64 bits in x64 mode).
So if your app uses VO GUI classes you are bound to x86 for now.
We have worked on an 'anycpu' version of the VO GUI classes, but that is not finished yet.

And w.r.t. your question about the Core dialect:
if you plan to use the Core dialect then your code should be "clean".
You started this thread with an example of a DbCreate with a 0 length for memo fields. This is not what I would call "clean code".

Robert

Hi Robert
I agree,
but, once upon a time i got a sample to made a DBF. and there was a zero for the length of a memofield. and before i was opening this thread i was searching in the x# documentation for a example and did not found one. maybe i dont know how to look there and the answer is a little bit hidden.
And zero for memofield is a logic value, because its a open size. i dont know whats behind the dbcreate function realy happends.
Horst