I'm not a FoxPro expert, but is there any functionality to script out the entire database schema, so that a SQL Server expert can look at that script, make modifications, and script it out in SQL Server? On that happens you'll have an empty database, then an SSIS developer can create a package to pump the data from FoxPro to SQL Server. This will likely take awhile to build, as the source to target mapping has to be accurate and in the order that is needed to handle foreign key tables. Might not be a bad idea to post this in Gigs to see if any experts bite, or at minimum find out if there's an expert here that knows both FoxPro and SQL Server. What do you mean by 'retyping all the field names after exporting'? To convert the VFP 9 data to SQL Server is relatively easy.

You may use the Upsizing Wizard which is delivered together with Visual FoxPro. Field names used in VFP should be supported in SQL Server. To create a drawing set for publishing autocad for mac free.

BUT to convert just data is far from the application porting. SQL Server is just a back end (or data storage with defined 'API') and VFP application also has the UI, it can print reports probably, etc. What tool or language do you plan to use for the UI and reports? VFP language is rather different from anything else and it the way it can access or process the app data is also different from other tools. VFP app can use its own SQL dialect which is partly compatible to SQL Server but some automatic port of existing command is impossible.

In addition to SQL you may use xBase language to process data and this is not similar to any SQL dialect you could know. If your VFP app uses DBC containers with stored procedures, triggers, and other rules then even the database port means a lot of work. So you should decide what is your goal. Some options are listed below: 1) Port the data to SQL Server and update the application code to work with these data - this means a lot of work but it also means a fast start because you can still use the existing UI while data are stored in more robust and more reliable environment. Such data can then be used by the newly created application in parallel with the old app. 2) Port the VFP application into some more modern, supported, and VFP compatible environment like Lianja or XBase (I have no experience with these tools yet) 3) Port both the data and UI - this means application rewrite from a scratch. You have to decide what tools to use and calculate what it will cost.

Ant it will be very expensive. 4) Leave the app as is. This has certain drawbacks like still less and less supported shared data access but it should work until the Win32API is present in Windows. This will be your option when you decide about 3) and finalize it. 5) Buy a new ERP application in a box and convert existing data to it.

This sounds very easy but you have to select the right ERP application, study data structures or API, write (or buy) the conversion program, then train users etc. BTW how many data tables and columns does have your existing ERP application?

Project Online For Mac

And how many lines of code it contains? Or even better how many man months was spent in the VFP app development? These basic values can help to estimate the cost of the port. This citation is from the mail obtained today: Finally, every once in a while I get a question about whether I'm still developing in VFP, and the answer is resoundingly yes. Five of my eight current projects are conversions or upgrades to VFP. If you're looking for help in a new or existing development project, please give me a holler.

Have a great end of summer! Whil Look at for more info. Pavel has laid it out pretty clearly and concisely above. A C programmer is finding it more of a challenge than he expected to convert the database to SQL Server 2014 Based on 20+ years of development I have found that your typical VB or C programmer will most often 'turn up his/her nose' at anything done in Visual Foxpro (Micro$oft's 'Red-Headed Step Child') and work towards a complete change of direction just so that they can be familiar with how things work - regardless of how well things work now. Pavel has asked: So you should decide what is your goal where he lays out possible paths.

Even before that I would ask: What is the intent of the change? What is the intent? Now with that intent defined, you can more clearly 'map out' the various 'paths' to possibly get there. After having, myself, developed a few proprietary ERP/MRP systems, I can attest to the complexity involved with the application operation (not just its associated data tables).

Converting the data tables is a minuscule effort (especially when using the Upsizing Wizard) when compared to converting how the application itself operates using those data tables. Keep in mind that 'converting' an application to another language could be like translating a book from English to Chinese. Since the various languages approach tasks in widely different ways, the code will not 'convert' line-for-line 'as is' into the new language. More often than not the application has to be totally re-developed as if 'from scratch' in the new language - only being able to use the previous application as a very general 'road map'.

Before delving into the development of a proprietary ERP/MRP system I generally recommend that the customer do a full, detailed Business Process analysis of their operations - each and every module of it and severely critique any of the 'proprietary' parts to see if they are really necessary. Generally the customers will 'discover' that they could be using an off-the-shelf ERP/MRP system to which they have applied most (if not all) of their unique business rules. That is - they have 'discovered' that they can operate just fine with a non-proprietary system. Thanks Pcelba and Jrbbldr.

Excellent points. I got the same email from Whil-very timely. The goal is to have an app that can be supported by programmers. Web needs are nil. At this point the main need is to accomodate EDI-very tightly integrated into the ordering, shipping and invoicing modules.

If we get a new customer that wants EDI, inevitably there are tweaks needed. So I have been training a fellow on that aspect.

I agree on the need for a long hard look before a rewrite, and that the table conversion to SQL would be the easy part. We have 150 tables (no rules or triggers). It's the many thousands of lines of code and the testing required that tell me the rewrite is not the obvious answer.

We do have some proprietary costing logic, but it is the EDI integration that I suspect will be the most difficult to achieve with off the shelf systems. Could be wrong, but a brief look a year ago suggested that most small to mid-sized companies handle EDI through a third party, with daily export and import of tables.

Ours is automatic, handling 90% of order and invoice volume. Pavel, I assume you meant 'until the Win32API is not present in Windows? Any reason to think that is coming? Can Microsoft afford that many enemies? These English negations.:-) I never know how to combine until with the rest of the sentence so better to avoid until.

It should work as long as Win32API is in Windows. And this could be valid for a long time because VB6 is still supported application and it uses Win32API.

The bigger concern for VFP is the shared files access. Sharing on local drive is still OK but sharing DBF files on mapped remote drive becomes less reliable and more problematic. Fortunately VFP application used via RDS or VFP app working as a COM server can work with data locally.

Importing Vfp Project To Lianja For Mac Os

I wrote a variety of EDI modules with or without Barcodes for VFP systems many years ago and there was no problem doing that. However many (most??) of today's direct inter-system communications is being done via Web-Services - no longer using EDI, but instead XML or some other format. Again no problem doing that within the VFP environment.

Regardless, if you are needing EDI, you first need to determine how many aspects of EDI you are needing to handle and how that inter-system communication will be performed. Look at: Some of these most likely will not be needed, but others (multiple ones??) may be needed And, once you Create the EDI document(s), you will need to communicate it with your 'external' partner in some manner or if you Receive the EDI document(s), it will have to be received in some manner and processed appropriately within your application. That communications method needs to be defined. Again, very do-able within your current VFP environment. If we get a new customer that wants EDI, inevitably there are tweaks needed. You should probably be open to the possibility that a new customer may want to use XML or some other more-modern means of inter-system communication.

Note: if you do a Google search for: ERP with EDI or ERP integrated EDI System you will find that a number of off-the-shelf ERP systems and/or 3rd party intermediary operations still maintain that form of communication. Almost everything is already said, of course, it's quite simple to migrate data. Don't use the native upsizing wizard, though, make use of the Sedna version, see Another possibility to recreate just the database structure is using the gendbc tool, which creates an SQL script. Not exactly one script, unfortunately, but a series of functions called. You can scrape off all CREATE TABLE statements at least to turn this into T-SQL syntax and create tables. I think the syntax gendbc creates makes use of single letter types (C for char, D for date, T for datetime etc). Also some defaults using VFP functions will not work 1:1, obviously.

To scrape off the SQL and to get the syntax working in T-SQL it might be handy to change gendbc code itself, perhaps start with gendbcx from As already discussed, this, would just be a basis for new application development with data in SQL Server. Note that even if the C#/C conversion occurs, you could still utilize the VFP data tables through an ODBC connection. One of my clients needed a web-centric version of their legacy VFP application so they created a VB.Net version of the application which runs through the browser (not a small task) and which connects to the existing VFP data tables through an ODBC connection (a relatively easy thing to do). This works perfectly fine - although most VB.Net or C#/C developers might initially balk at that approach. So unless you are running into the 2GB file size limitation or you should need better data security you should have no current 'burning need' to make the data table conversion to SQL Server. Keep in mind that when you make that change, your VFP application (should it still be Active) will need a good number of changes to utilize the data. I suspect you are right-this would not be the developer's first choice.

If your company is committed to actually going through the not-insubstantial development expense to totally recreate the application in another language such as C#/C then you might as well go ahead at that time and convert the data into SQL Server. In that situation there wouldn't be much to gain by leaving the data in its VFP data tables and it could be done quite readily using the tools that Olaf & Pavel have mentioned. However if the 2 applications (original & new) needed to co-exist for some time such as during testing, etc., then leaving the data in their current VFP data tables would be best.