Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

xbase++ - conversion from Clipper! 2

Status
Not open for further replies.

GriffMG

Programmer
Mar 4, 2002
6,304
FR
Hi All,

A few weeks ago I posted that I was converting a large Clipper App to xbase++ and thought you might like an update.

Today the client accepted the xbase version.

There are some gotchas (I'll write em up in a bit) but overall the system is faster and prettier.

Two things nearly got the better of me and are worth mentioning.

1) Look out for variables with long names - Clipper ignores the 'extra' xbase does not.

2) In Clipper you can restore a screen from a variable that has been 'declared' but not given a value (i.e. is probably NULL) - xbase does not like this at all.

TTFN

Regards

Griff
Keep [Smile]ing
 
Thank you.



Regards

Griff
Keep [Smile]ing
 
A follow-up to my previous note...

The client accepted the system about a week ago, but only got round to trying it multi-user this week and it runs like a dog compared to Clipper when there is more than one user!

I've upgraded to 1.82 and it isn't any better, are there any tricks to getting xbase++ to run quick on a network?

TIA

PS sorry for duplicating this message !

Regards

Griff
Keep [Smile]ing
 
Solution!

In clipper the process of doing a 'goto' or 'set order' that doesn't change anything is essentially instant. In xbase it isn't, it either places a lock or flushes a buffer (don't know which).

In my programs - this report for instance - I use UDFs to get and test related tables and store the full table state on the way into each one and restore it on the way out.

So... if I am looking at 50,000 records and do 10 look-ups on each and then save and restore the position and order of 40 tables the overhead comes in a multiple of 40 million flushes or locks! Hence why it was so slow. So, I've made the routine that restores the positions and orders test to see if they have changed - bingo, back to 'quick enough' at a stroke.



Regards

Griff
Keep [Smile]ing
 
I've been using xBase++ for a couple of years now and find it amazingly compatible with my large installed base of Clipper code. It took a while to get comfortable with xBase++, but now that I have it has slowly become a very productive platform for my needs.

The only serious compatibility issue is where I utilized a third party library (T-Base graphics functions) to build a document processing system (scan/store/retrieve documents) and have yet to find a suitable xBase++ compatible replacement that easily replaces the functionality I utilized from T-Base.

There have been a few small (challenging) coding differences, but I'd say that overall approximatly 98% or better of my Clipper code is readily recompiled with Alaska xBase++, often only changing a single function name to Main().

I've not yet spent a lot of time with Alaska's GUI interface options for my applications - but on the few that I have explored - it works great.

The ODBC connectivity provided by Alaska xBase++ opens some doors to our SQL oriented data storage for future applications. I'm just beginning to explore those capabilities.

NOTE: The latest project by Alaska is to expand xBase++ compatibility to the Linux and Microsoft .Net worlds. If they do indeed get Linux compatibility - that opens a LOT of doors for the future...doors that don't have a Microsoft toll gate on them! ;)


 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top