>Rod,
>
>>The application listed is the DSS application (data warehouse)
>>The OLTP application should show up on the list sometime soon. It has comparable data sizes to the DSS application and uses stored procs exclusively. Like all sql server apps should.
>
>1. First you say that you should not use DBFs anymore, but something else like SQL Server or MSDE.
>2. Seconds you say that when using SQL server you should use SPs.

>>>So how the hell would I implement an application that is backend >>transparent. The fact is that RVs do add a transparancy layer to the >>design with SPs do not. Your argument does not make sense to me.

>My answer to this is: I wouldn't. I don't engineer my applications to be back end transparent. I am not SAP, Peopleware, Siebel or another ERP vendor. Engineering an application to be back end transparent is too costly and most clients wound not justify that expense.

Good for you. We as VFP developers have always been told to use local views in stead of direct VFP access because when the day comes that you have to go SQL, you won't have as many problems. It certainly is not rocket science to make your app DB transparent. You only need to restrict your communications with the backend to standardized SQL and for very specific cases: write custom code.

>Also you are not being very realistic on this one. The differences between oracle and sql server are great especially when it comes to data types.

That is why RVs are great. They hide those differences.

>Generic back end transparent applications cannot take advantage of the cool features of a database. Like Oracles Java stuff or SQL Servers XML stuff.

I'm saying that you don't need a lot of that cool stuf. Why doing stuff on the server that can be done on the client ? Beats me. A SQL server is a SQL server and it should serve data through SQL. I'm not interested in propertary stuff. Not trying to load the server with functions that can be accomplished much better on the client. I don't need to write SPs to datamung a result set for reporting. VFP as a client tool is much better in this than SQL server.

>You sure assume a lot about what I do as a developer and what I know as a businessman. I am well aware that there are lots of mom and pop operations out there. I am also aware that supporting them takes just as much effort as a large client. I don't like working in that market. So I cede the mom and pop market to you. You win! No competition from me.

Well great, so why do you (and JVP) are trying to project your 'best practises' in markets where you don't participate and do not understand? The fact is that these are very different markets and have very different requirements. I thing you and JVP don't seem to understand. Taking the arrogant stand that what is best for the tailor made applications you make is best for all applications in the world is beyond me, and does not prove of any intelligent understanding of general database application practises. Further it does prove you not to understand what 'data driven' applications mean.

ERP applications are examples of data driven designs and though in general it would be foolish try to be a big player in this market you can easily copy some of the characteristics of ERP designs JUST BECAUSE YOU ARE ABLE TO USE A LOCAL DATABASE ENGINE. As I stated in an earlier post, you can do a lot of data driven mechanisms within VFP application by making use of a local database engine. On the fly query construction, advanced security, data driven menus, even localisation are examples where data driven designs with a local database engine can play a big role. This is not something I would try in .NET because of the ommision of a local database engine.

Fact is that .NET is leading you nowhere when it comes to designing data driven applications.

>Next you talk about standard software (what I call shrinkwrap or commercial software) and how it is much different than custom client software. You claim that it is more complex to develop, has a greater # of ER's, etc. You also claim that it is more difficult to write. You are incorrect. It is no more difficult to write a shrinkwrap app vs a custom app. The requirements are different. That's it plain and simple.

Prove me I'm incorrect. Fact is that with tailor made software you've got a fixed set of specifications. With commercial software you don't, You've to do a lot of research and become an expert in the domain before you can make a decent program.

Question: Why is 95% of tailor made software not resellable to other clients ?

>BTW, one million for an ERP package makes me think that what it does is trivial. My guess is that SAP, Peoplesoft, Siebel, etc. Spend more than that in a week.

This was not an ERP package. This was a tailor made project.

>>>I do know from experience that you have to have very decent skills to >>write a decent standard software package, while about every idiot can >>write custom made software: As long as the one client is happy it does not >>matter how the architecture looks like. And if it was rotten to the core, >>you just say, we need to do extensive programming to build this feature, >>and the client most of the time has no choice than to accept the >>consequenses.

>>> Your and JVPs standpoint do simply not make sense in this world.

>You are way off base here dude. You assume that all custom apps have poor architecture. How do you come to this conclusion. Let's see: how do you take a 60GB application and go to over 800GB in 5yrs with a bad architecture ? I guess I was lucky on that one.

Where did I say this? You have to read what I say carefully before jumping to conclusions (as a good developer will). I did say that you don't need a good architecture when writing tailor made applications. In fact every idiot can. This is much more a requirement when writing commercial apps or it will hunt you when trying to compete with other compatitors.

Tss, tss, You should know better than implying that the size of a database say anything about the complexity of the application. Even the number of tables or the size of the application itself does not say anything about complexity and architecture. I've written very complex algoritms in just a few K and only taking very limited amounts of raw data, just to do very complex analysis. While in another project the application is merely recording information about certain transactions in which the size grows real rapidly.

>Is this not what we do when building custom applications ? How is this any different? Please enlighten us all.

Typically you don't do that to the extent as you have to do with commercial apps. The specifications are given by your client. You even might not be the one doing the analysis and basic design of the system and or domain. In many large projects the task are strictly divided and noone does work on all levels from analysis to actual coding and implementation. The tasks are strictly divided. This is also one of the causes why so many IT projects fail.

With developing commercial software you are much more driven in understanding the domain as the domain of one client might slightly differ from the other client. You've to find a balance between different ways of working and have to work more modular to enable/disable modules/objects that are not used by some clients. One client might not use the financial module while another might not use the stock keeping module and another only the appointment scheduler. Further definitions of business rule might differ significantly. This makes writing commercial projects more complex and data driven than the more fixed tailor made software. When you look at your written tailor made software and carefully judge what needs to be change to make it commercial, you'll see what I mean.

Any way you put it, tailor made software is software that is (only) satifying the clients need. You know what the client needs at forehand, not neccesarely knowing all the details about the business domain. This makes that virtually all tailor made software is useless for the clients compatitors because they probably work through a slightly or completely different workflow or even record and analyze different data.

>>>Your and JVPs standpoint do simply not make sense in this world.
>Let's see: Use SQL Server (or Oracle) Stored procs, Use VS.NET. Don't use DBF's. Guess that is my standpoint then.

VS.NEt is off it does not have a local database engine to fit the needs of creating data driven applications. And SQL server, Oracle and even MSDE are not viable choices when writing a mom and pop applications for the grocery store on the corner. As you said MSDE is more difficult to install and is more suspectible to all kinds of problems like virusses and mallfunction than a plain DBF solution.

>Have a day,

Thank you,

Walter,