Ed,

>>The solution I choose is to calculate the remaining leave (and other data) hours when requested. To maximize performance when the remaining leave hours of large amounts of persons is requested (for e.g. in a report), I've got the whole mechanism tuned for performance and now it takes about 0.03 seconds to calculate the leave hours for one year for one person. I've had to use every trick to save CPU cycles and test various data handling mechanism to accomplish my goal. Within a loop of 366 days each CPU cycle won is important.
>>
>
>Walter, this is raw, unadulterated bullshit, or you haven't thought about this for 2 seconds.

It took me tree day to accomplish the goal, so I've had plenty of time to think about this.

>Probably both. There's no serialization necessary in the process. Take a dozen bullshit systems, partition the data set into isolated domains, and go. Use old bullshit 486 boxes. Use a couple dozen boxes. There's nothing blocking inherent parallelism. I just scaled your app back to run in 1/10th the time with at most a minor code change. And I can throw more iron at it faster than and cheaper than you can creeb cycles. This ain't mission-crticial, real-time event duration sensitive work, Bucko. Get a clue. Get a life. Get some concept of what you're saying, because if it's cycle-tight, not real-time, and not inherently serial, throw more hardware at it. IRON AND SAND IS CHEAP. FUNCTIONING BRAINCELLS ARE NOT. I worked small scale lab systems with event duration response limits, and have written device drivers. And I've writen things where one box couldn't do the job, so
>we did, hmmm...could it be...distributed processing?


The whole process is serialized and can't be split up in several processes. The whole process looks in about 5 different tables so DML actions are important. I simply can't see how parralism would improve performance here.

Clearly you don't have a clue of software development in general. Do you even talk to your clients for a moment ? If you know what you're saying you would be ashamed for this message.

HOW ON EARTH am i going to tell about a 1000 government users that I can't speed up the product because I should not use the (as you call) it outdated techniques of xbase , so they'll have to upgrade their hardware. Not in a million years they would buy this. Here in the Netherlands we have a saying that the client is the king. Clearly you don't ever heard this.

Furter on, we don't have much to say on which hardware and OS it is going to run on. We've got already much trouble using third party software like Crystal Reports in our products, so we are not waiting for more trouble. SQL-server is not an option either. Not every client has SQL-server running, and certainly has not the ability to either purchase or maintain it.

I'll guess you've only got projects where you can use the hardware you want and you are always available for troubleshooting on site to fix the problem. Well I'm not that fortunate. I've got to deal with numerous clients which work with the same product on different hardware and (N)OSs. I can't go up there and troubleshoot the problem. Therefore the product must be very stable and the potential problems must be known and a solutionplan must be available.


>Walter, I'm not impressed. Like I said, you're bullshitting or stupid - take your pick. I'll assume you're convinced you're smart Walter. Go convince your clients. I have work to do and people with a clue who ask semi-intelligent, rational questions. For a "theory heavy" expert, you just don't know jack.

You may have your opinion, my clients have their own. Frankly I don't care what you or anybody else thinks about what i'm saying. I simply strongly disagree with your standpoint on software development within VFP. As John K. likes to say 80% of all thing is CRAP. I like to find the crap in software development. You clearly find my way of development CRAP but you can't give any real arguments which definitely prove im telling crap. From my point of view you're driven by hypes rather than common sense or knowledge. You clearly don't have much experience in developing standard software packages which are sold to many clients. If I look at the *most* standard packages sold today I do not see that:

- The software requires to run on the newest and fastest hardware.
- The software uses the latest (read experimental) technologies for dataacces (Hmmm what happend to RDO, RDO2, IDAPI, Jet, etc)
- The software requires a DBA and a network specialist to run.

It's hypocritical to think that it's an ideal world out there. There are lots of incompetent DBAs and system administrators which have to install your product, lot's of users which do stupid actions that cannot be reverted etc. Therefore i'm on the standpoint that my product must be as much VFP as can be. Though I certainly use activeX and (D)COM in my products, I certainly would like to get rid of them if possible.

>You don't know the terminology. You don't even know the platform.

Examples please ?

>>However, I've got several cases (like the one described above) where SQL is getting you nowhere and leads to serious performance problems. Especially where performance is very important, I'll look for alternatives like xBase constructs, which can do the job SQL can't.
>>
>Failed imagination is about the best you're gonna do on this.

???

>>The difference between you and me is that I want the fastest tool for the job and you only want to use SQL even in cases where it is doing a very poor job and refuse to even consider an xBase eqiuvalent.
>
>Then why in all of hell do you use VFP? VC++ will blow away VFP for math, and I can spin through files that use indexed access using a ton of faster mechanisms than VFP can put to use. The closest you've gotten to speed might've been some benzedrine you popped in school. If you're really convinced you have a clue, why the frack are you burning cycles interpreting p-code for a living?

VFP is my main development tool, I could decide to make certain parts of the performance critical things within C++, but:
- I'm not as comfortable within C++ as in VFP.
- The most things are not going to be very much faster within C++ when it comes to DML actions.
- Life is too short to code in C++

Only in a very few cases where performance is very critical I'll find C++ as an atractive alternative.

>>Let's take the following example:
>>
>>An employee table contains an emp# and a chief#. The chief itself is also an emplyee and also has a chief. The following two examples gets the upper chief of a random employee.
>
>Stop. I dump a relational model and put up an app based on ObjectStore used as a network-model database and use a language platform with an internal concept of list and direction. Case closed. Oooh, no fair - I picked a tool that has a clue about lists and digraphs. I have a clue what a digraph is...

It can be very nice in your case, but the following disadvantages come in mind:
- I've got to work with another database, which I don't know
- I've got to purchace it, probably not only for me but also for all the clients,
- I've got to be sure that I can solve the potential problems only by telephone or E-mail.
- I've got to use a database which for the most common relational DML actions has a very poor performance.

Get real, why the hell I want to do this, when I can easely achieve the same within VFP ?

I'm not going to fight another battle with you ed. If you don't want to respond to my messages in an adult, constructive and professional way, then please don't reply.


Walter,