Help with purchase 1

[qlark]

I used Foxpro back when it was still FOX software and now have a project that needs a fast track development.

Can someone please tell me which version of VFP 9.0? I need to create a stand alone (read licence free VFP distribution) apps for a small (6 PC) multi user application. This app will be located on one of 6 peer-peer pc's and must be able to have all pc's run this app without having VFP installed.

 

[Olaf Doschke]

Hi qlark,

Schus

I recognized what you ment .
It's "Tschüß" (html: Tschü&szlig Pronounced a bit like "Choose" with a much more sharp s at the end.

Well, the showstopper is, VFP data can get corrupt in the same way as access data, it's still a file based database.

Perhaps the network and hardware has more influence on the high number of corruptions. And as with Access, the corruption may be in a table or index days before you get the first error.

The advantage is, with VFP databases you have many individual files and not just one big MDB. If you take precautions, log data and backup, you can save the day most of the time without much loss.

Bye, Olaf.

 

[qlark]

Olaf

I know this is off topic just brings back fond memories of the Rheinland almost 20 years have gone by since my last visit maybe its time to plan another trip.
..
Thanx for the spelling of Tschu(sz) Sorry don't have my German character set available for the umlaut and SZ ... One question on the pronunciation ... my father who grew up in Bonn Bad-Goddesburg said that in high German the Tsch is a CH sound and in low German its sort of a SH sound like Shoess instead of Chuss? The Frankfurt and Bonn family use the Shoess version.

The last time I was in Germany visiting family this was their polite way of saying goodbye. Glad to hear this is still a common jesture.

 

[qlark]

Mike

It was just a spur of the moment thought ... in this application there isn't a real issue with speeds for updates so a transaction loop of some sort could work fine ... with an xml file concept, the client application would validate the xml file first then copy it to a server folder, and finally do a simple file compare to validate the file on the server. The server could then be triggered in any number of ways to process the xml transaction file ... any errors could be sent to the administrator (any errors at this point should only be code related anyway as long as the XML template is defined properly) ... the XML transactions can then be archived for a length of time to allow for backup recovery etc. Using this concept there is only one process that can update the database so there is no worries of lock contentions etc.

With the type of data involved in this application it will be extremely rare for two client machines to be looking at the same data at the same time plus only two out ten users have update privileges so it is resonable to expect that the clients will get the correct data the next time they go to use it.

Of course this would not be great for anyone that needs immediate updates. But a server app like this would be fairly simple and I suspect would be more economical then purchasing licences for a product like SQL-server.

The network we have is 100Mbit SMC backbone to DELL 2.4G Hz Optiplex with 1Gbit network cards all wired with cat-5 ... the longest run is 60 feet or 20 meters ... all machines are on UPS and running Win2K pro ... I am not rulling out there could be an issue with the network somewhere but this is not the only application running off the server but is the only app that is falling down.

 

[Olaf Doschke]

...brings back fond memories of the Rheinland...

If you were there, eg in Cologne, they say "Tschö" (Tsch&ouml) without the sharp s at the end. I can't think of a similar sounding word right now, regarding the Ö. Like Ä (&Auml and Ü (&Uuml it sounds quite similar to the letter without the dots on top. It's true the don't pronounce the T that sharp too, it's almost silent.

Regarding your idea of XML, you could set up a webservice and work with XML update grams. Take a look at the command available since VFP8:

http://msdn.microsoft.com/library/d...html/646e7dbb-d5e9-4017-b8a2-cb3625a818cb.asp

You seem to be familiar with XML, I think I could learn from you about that, my XML knowledge is still rather limited.

Bye, Olaf.

 

[qlark]

Olaf

That link looks very interesting ... XML in concept is not that hard to understand ... I had to do a project cold turkey (no knowledge of XML) several years ago and at that time I found several sites that had a 5-10 minute course on the mecahnics of XML ... I did find that just like in electronics, someone comes up with a new standard and everyone interprets it differently. From my perspective XML makes sense for a number of reasons ... when passing fixed or comma delimited data files, ALL of the data fields MUST be always present plus both send and receiving end of the data MUST be in sync. With XML the only data that needs to be sent is data that is changed and that data can be sent in any order (the best example of this is M/D/Y, Y/M/D, D/M/Y In XML we would send D, M, Y and the receiving app can put this in any order it wants). The last thing is that if there are DB structural changes on one end of the process (within reason of course ie like adding a second phone number possibly to a contact) Applications can be designed to ignore data they aren't prepared for so parallel development can go on without having to be in total sync.

XML does have one issue from a security perspective, because it is very descriptive (again depending on the design) each data element is labeled in the data file ... if there is critical data in the file and it is intercepted the data could be easier to interpret. I presume Data and Labels(tags) could be encrypted in this instance and or the whole data file could be encrypted.

 

[Olaf Doschke]

Hi qlark!

I did find that just like in electronics, someone comes up with a new standard and everyone interprets it differently.

It's that what keeps me outside of the "XML temple". The concept of XML you lay out as a general explanation is very nice and understandable. It's the different flavours that make it hard to work with XML, eg DTD vs Scheme. Well - it's the X in XML - extensible - which makes it so flexible, I understand you need to pay for that extensibility somehow.

Unfortunately the VFP XML functions are rather limited in creating and consuming XML, so the VFP implementation of XML is rather self contained in that respect.

If you have more complex XML you need to parse it yourself. STREXTRACT() is a nice function for that, the funny thing is, I think that function is much older than XML and seems to fit perfectly for extracting parts of an XML file. The XMLAdapter is also quite helpful, but that makes use of MSXML 4 or higher as the parser, which really has the work load. And in my experience - from using CURSORTOXML and XMLTOCURSOR to transfer a cursor from one datasession to another - it's rather slow.

Bye, Olaf.