Tanvir, 1. VFP Run Slowly Firstly if you can find anything to run faster than VFP, please tell me - short of assembler code. VFP will handle networked installations no problem at all. The slowness will probably be because of the way the system is designed and/or due to the lack of optimization of the data indexes and nothing to do with VFP per se.
2. Lack of Unicode support Sorry, but I never get involved with Unicode so I can't help here. Maybe some others on the list may well like to comment. 3. Tables corrupt if the power is cut. Well the obvious solution is to ensure that the power isn't cut. You can protect the data to some extent by wrapping any data up into "Transactions" using basic VFP commands as well as using file buffering (See Andy Kramek's excellent paper on buffering for more details). Better still, implement a real client/server solution with proper power protection on the server using M$SQL or MySQL with VFP as a front end, which it is excellent at. In any "unstable power" situations, there is always a chance of power loss whatever language you use so VFP is in no worse a situation than C#, VB etc etc. The secret is in good design to minimize the potential problems of data corruption. As the saying goes - rubbish in, rubbish out x 1000. However, your solution should never be designed to overcome the inadequate environment. It is better to solve the underlying problems (eg Power) first as opposed to programming around it or the problems will never go away, just get bigger and more frequent. Also you need to look VERY carefully at your backup procedures in an unstable environment, whatever solution you end up with. The only real solution programming wise, to your problems is a better in depth understanding of the language you are using, be it VB.net, VB, C# or VFP. I use all of these languages and VFP comes out the top for speed of development and execution. I will continue to use it until a better/faster solution appears which doesn't involve the vast learning curve of the modern day languages. Post away with your problems in the group, there are always people who will give good unbiased advice and we all have many years of developer experience for you to call upon. Ask away. Dave Crozier -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of tanvir ahmad Sent: 18 January 2008 15:02 To: ProFox Email List Subject: Re: Grid value send to Excel thanks dave i m using vfp-9 i like very much, but i want to switch vb.net, for only 3 problem 1-vfp run very slow in network or local area network 2-it's not support unicode 3-it's table has been currupted if power cut sudenly what can i do. plz give any suggestion On Jan 18, 2008 2:36 AM, Allen <[EMAIL PROTECTED]> wrote: > I would normally create a csv file as I go. DataToClip will create the > data > but not headers. > I do this a lot to create excel sheets unless I go with automation. > scan the table adding values with "," between (dont forget to trim) and > dtoc > dates and the like to a loacl var. > Make you column headers first also with "," between. > I make this as a var then stringtofile after. (.csv). This can be read > into > excel. > Note excel buggers up csv files. It replaces dates with its own type for > one. > Allen > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On > Behalf Of tanvir ahmad > Sent: 18 January 2008 11:17 > To: [EMAIL PROTECTED] > Subject: Re: Grid value send to Excel > > Thanks Dave > u'r advice is working very well but my requirement is sent grid value with > header caption or report sent to excel. > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.19.6/1230 - Release Date: > 17/01/2008 > 16:59 > > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
