Replacement for VFP

[grahamrhind]

Much as I love VFP, I am increasingly battering myself against VFP's lack of true Unicode support, and I need to start looking around for a replacement. I'm sure others have been doing the same. So, can anybody recommend a PC-based database program which:

- has full Unicode support
- has command-line abilities
- is as powerful as VFP in its data manipulation (I do not, and shall not be making any programs for others - it's all about the way I can handle raw data).

Any pointers would be much appreciated.

Thanks!

Graham

 

[bborissov]

You could check SQL Server Express with SQL Server Management Studio Express. But with it you CAN'T create User interface Forms, Reports etc. You only can handle RAW data.

Borislav Borissov
VFP9 SP2, SQL Server 2000/2005.

 

[Mike Lewis]

Graham,

Like you, I've been frustrated by VFP's lack of Unicode support. But I don't necessarily see that as a reason to ditch VFP entirely.

It really depends on where you want the Unicode support. If you need to store Unicode text in database tables, there is a good choice of back end databases to choose from, including SQL Server, SQL Server Express and MySQL. You can use any of those -- or many others -- to store your data, and still use VFP as your front end. In fact, Unicode apart, there are good reasons to do that.

If you need to let your users read and edit Unicode in the user interface, there are plenty of third-party controls that will help you out.

Having said all that, if you do find something better than VFP that will meet your needs, by all means give it a try.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[grahamrhind]

Thanks Borislav and Mike.

I admit to having a horror of software using the SQL language (which is a step back to the stone age in my mind), and an equal horror of client-server. That said, I'll have a look at SQL Express.

I should probably explain more the issues involved. I don't just store data, I work with it on a daily basis and resell it. I therefore need all of the tools that VFP provides: browsing, command line find and replace, macros for quick cutting and pasting, that sort of stuff. At the moment, I have to store all of my data duplicated in two fields. One has the data in ANSI 1252 format. The other contains a "Unicode" version, but with the Unicode value replace with a numeric equivalent, as I can't add or store Unicode in VFP. Thus, one field will contain "Istanbul" and the other "<0130>stanbul". This loses me customers because they then have the onus of changing all the <0130> to a dotted capital I.

If I can easily use VFP as a front-end to SQL Express (with the emphasis on easy - I'm just too set in my ways!), then that might be a way to go, though I'd prefer a standalone desktop solution.

 

[bborissov]

You could "easily" use VFP with ANY kind of BackEnd database. Just look for RemoteView, CursorAdapter and all functions that begins with SQL* in HELP.
About HOW to work with UNICODE in VFP check this:

http://www.west-wind.com/presentations/foxunicode/foxunicode.asp

http://www.west-wind.com/wconnect/weblog/ShowEntry.blog?id=608

Borislav Borissov
VFP9 SP2, SQL Server 2000/2005.

 

[grahamrhind]

Thanks Boris. I should also have said that I have close to 30 million records, split into 12 databases of between 1 and 4 million records in each, so it's preferable for me to work on the raw data using indexes to sort it than to run SQL queries to get the data, which I think would be pretty time consuming and rather killing for the PC.

 

[bborissov]

No, such amount of records is NOTHING for SQL Server. If you have proper indexes your queries will be VERY fast.
4 mils of records in one database that means that this database have a VERY good design, just have the same design in SQL Server but instead of CHAR field use NVARCHAR type.
SQL Server is much more better that VFP Native DataBase. It is FASTER (again of you have proper indexes), it can handle MORE data than VFP.
One huge drawback, it has NO User Interface. So if you work ONLY with Raw data you can use it. You can create Stored Procedures which can returns you only needed recordsets. You could use Functions, you could use everything you can imagine, but w/o user representation layer (no forms and reports).
BTW if You buy Developer edition (about $70) you have FULL workable SQL Server Enterprise Edition on YOUR computer. Than you have Reporting Services, Data Transformation Services etc.

Believe me Transact SQL (or T-SQL) is not that hard
Also if you have any questions about it you could ALWAYS ask here in "Microsoft SQL Server: Programming" forum.



Borislav Borissov
VFP9 SP2, SQL Server 2000/2005.

 

[Mike Lewis]

Graham,

I admit to having a horror of software using the SQL language

Just because you use SQL Server (or MySQL, or anything else with SQL in the name), it doesn't mean that you absolutely must learn the SQL language -- although it certainly helps to have a grasp of it.

For example, you could use remote views in VFP to access the data. You can use the interactive view designer to create the views, and, once you've done so, treat them just like ordinary Fox tables, that is, DBFs.

Actually, that's an over-simplification. I wouldn't normally suggest that appoach exclusively. But if you really do have a horror of SQL, it will at least get you started.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[grahamrhind]

Thanks for all this.

Is it really the case, though, that there are no non-client-server or non-SQL alternatives? I was defeated just trying to install SQL Express, and it seems over complicated for what I need.

 

[bborissov]

Non SQL, with its own database - sorry never heard of it.

Borislav Borissov
VFP9 SP2, SQL Server 2000/2005.

 

[Mike Lewis]

Graham,

If you're simply looking for a stand-alond desktop product with which to manipulate your data -- yes, there are some possibilities, although I doubt you'll find anything that gives you everything that VFP offers.

Off the top of my head, I'd suggest you look at Access and Filemaker Pro. I don't know to what extent they support Unicode, or could deal with the volumes you have in mind. But you've got to start somewhere.

Personally, if I were in your shoes, I'd grasp the nettle and teach myself SQL -- it's not all that difficult -- then go for SQL Server or MySQL.

Let us know what you decide.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[grahamrhind]

Thanks Mike. I'm looking currently at Access, which has better Unicode support than VFP, though I haven't been able to find out yet the depth of that support.

I do know and use the SQL language (I dislike it and avoid it, but use it when required), so that's not the main issue. I am more concerned about the technical complexity of programs such as SQL Express. The amount of steps required to install it is bizarre (and very un-Microsoft like) (and it failed to complete for me for some reason unknown to me); and I'm worried about trying to get data into it and work with it while trying to work out whether servers are running etc. etc. - I don't have a support department who can help me out with that sort of thing.

I may end up working with the data in VFP, then when a release is required, creating a related table in Access and adding the missing Unicode characters. Not ideal .....

 

[craigber]

You're going to hate Access. As the data file size grows, the performance issues increase too. Just don't go there. Bite the bullet and go with a server-based system and learn some minimal SQL commands.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com/blog

 

[TamarGranor]

Your feelings about the SQL language suggest to me that, even if you know the basics, you've never really spent the time to get comfortable with it. SQL provides a much easier way to access data much of the time because you specify what you want rather than how to get it.

VFP's native SQL is very fast. For anything involving more than a single table, it's almost always faster than the corresponding Xbase code. For single table stuff, it varies, but as long as your queries are optimizable (which follows the same rules you need to in order to make FOR clauses fast), it's blazingly fast.

Tamar

 

[grahamrhind]

I think this thread is veering somewhat, so forgive me if I try to bring it back to the initial question - we'll just have to take it as read that I use SQL within VFP when appropriate and xBase when appropriate

The issue is lack of Unicode support, and that's it really (if VFP had Unicode support I'd never change to another program). Most replies up to now have suggested a move to a more technically challenging client-server solution - SQL Server, MySQL etc. My understanding is that, even if I were able to install and use those packages, they don't have their own front-ends and using VFP as a front-end would not be an option because SQL Server etc. may be Unicode-enabled but VFP is not, so I would still not be able to enter Unicode data into the VFP front-end. (This is not about storing Unicode data but entering and working with it via BROWSE and equivalent).

I would be surprised if no VFP users considering a move to another package opted for simpler, desktop, alternatives, such as Access (which I certainly wouldn't want to work with on a day-to-day basis, but which CAN allow Unicode data to be added when working with raw data).

Again, this is not about program- or interface-writing etc. - it's the basic open, close, browse, edit, import, export functionalities with the raw data that I need.

So, if anybody can suggest a desktop alternative, closer to the power of VFP without the added technical back-end complexities, and which is Unicode-enabled, I'd be very much obliged

Cheers!

 

[jimoo]

Here is one I have heard a lot of buzzzzz about, but have not personally checked out:

http://www.vistadb.net/

Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[grahamrhind]

Thanks Jim. It looks like VistaDB promotes itself mainly as a program for (multi-user) application development rather than as a tool for data management; and I can't find a reference to Unicode, but I'll give it a test drive!

 

[gfrlaser]

Forgive my ignorance. Can someone explain the basics/benefits/fallbacks of Unicode database products versus say, my favorte, Foxpro. What is and where can I research a Unicode product?

 

[grahamrhind]

Unicode is a consortium of hardware and software manufacturers, whose system allows many more languages and scripts to be entered into a database than the old ASCII and ANSI systems.

Foxpro uses computer code pages, and each code page only allows support for a limited number of languages. Thus, you could choose one code page and cover Western European languages, but then you could not enter Eastern European languages - the accents on the letters in those languages would be corrupted. If you changed to Eastern European language support, you'd lose support for some Western European languages, and so on.

Unicode allows most common languages to sit in the same database. Many people won't need that if their data comes from one country. As my data comes from all countries, I need to be able to have that extra language support.

Hope that helps!

 

[Olaf Doschke]

Grahamrind,

I'm sure you know you can store codepage independant binary data in both binary char/varchar and binyr memo fields, the worst problem is to not be able to use native VFP controls to show more than one language, if you use unicode capable controls (eg ActiveX) ou loose the easy data binding by controlsource.

Handling strings is the next big problem, as most string functions only work on ansi strings and as soon as you have double byte characters even simple things like string concatenation are harder to do.

So handling unicode is not very simple, but you got to decide if handling data simpler is worth the effort you need to invest for string handling functions. You have some support with Strconv(), SubstrC(), RightC(), ATCC(), AT_C() etc. but if you say you already work with data in many languages you surely know this and have come to a point where this isn't sufficient anymore.

Another solution, that's also not very effective, is to put anything needing another Ansi code page into a webbrowser control. You then could do a web app instead of a desktop app anyway. This is like moving away from VFP within VFP by using less of VFP itself and more and more from webapp technology.

The final question is, if you find a unicode capable language that can handle data quite as simple as VFP. Access may come the closest, but lacks OOP. Anyway you need to invest in reoing some part of your app, either unicode handling by staying in VFP or data handling amongst other things, that are easier to migrate, by moving away from VFP.

Bye, Olaf.