Your client can place locking records in your database to point out that a user has loged in (like semaphore locks). At closure of the client the record must be removed. In our system we have a special server application that checks every minute whether a lock is still valid, and otherwise removes it. Upon a crash of a client you wont have a lockout for long. To be able to see who has accessed the data, you could make an audit system: Log which user signed in from which computer, what he has done etc. This can be done by various methods: - the client app writing extra records - triggers in the database - the higher versions of SQLServer have tables that store information about performance of performed queries etc. Maybe those are helpfull also. - ...

Regards ... OttO

Thanks, your extra vote no.2 for this approach.

Regards ... OttO

The beauty of a meta language is... you can create your own. It can also be a pitfall.

Regards ... OttO

Do you think that the mainlogic source will be different for the different platforms? Or only for certain portions? If the code is (for the most part) the same: Couldn't you use SCC and share the code over different projects? If the code is different, could you use an automatic code converter? We had worked out such a scenario for going from a dying language (VO) to .NET (Vulcan). During the transition period (a year) the code would be transported numerous times from VO to Vulcan until all of it would work. Parts would need a rewrite. The VO code would be adapted too if possible to make the transition possible. The VO code needed to produce valid apps all the time. An alternative: can you make an abstract in meta language for the 'complex operations'? You can use a code-generator to create the code you need in any language.

Regards ... OttO

Thanks for the info.

Regards ... OttO

Thanks for sharing. :) We are considering the same at the moment. That's one vote extra in that direction.:thumbsup: So, you don't check the db structure? Do you use different database versions (SQLServer 2000, 2005, 2008R2, maybe beside those Oracle, MySQL etc)? How do you get the most of them from within the same application? I think I will go for a sort of abstract factory pattern to support the different possibilities of the SQLServer versions. Other database types aren't in the picture at the moment fortunately.

Regards ... OttO

Ofcourse, I agree on that. Nevertheless: how do you signal all kinds of mischief? (the described situation is only a example, maybe not as realistic in a live situation at a clients site.) How do you deduce that a database of a 'strange' origin is attached to your application? Without crashing the app on some non-descriptive error like 'error in query'?

Regards ... OttO

My questions are: Does your app check the db structure? And how? And how do you deal with a change of database version like from SQLServer 2000 to 2008R2? How do you take advantage of datatypes like VarChar(max) which is available in 2005 and further, but not in 2000, without forcing all clients to migrate to 2008R2? I then got a question 'why would you check the db structure?' upon which I described a not so fictive situation WHY I would want to check the db structure. See my previous post. I've seen this kind of situations numerous times in the past, most of the time here in the house: 'I have a db, don't know the version, but it works' X| a few hours later: 'oh no, it doesn't work' Backup's aren't the problem. Stupid users and ignorant developers are.

Regards ... OttO

(was away for a few days) Sorry, miscommunication: I meant to say: The software was updated, and in the update proces columns and tables are added, and sometimes the content of some tables will be altered. The client doesnt add the columns etc, only performs the update of the software. The client restores an older database. And as result of that, the application crashes after a while, for instance a month later. And I agree: it is the problem of the client, not ours in the first place. The problem is that the updatertool hasn't updated this backupdatabase. Because of this: - a month work has been added in a not so healthy environment X| - corruption/inconsistencies in the db are possible. Nevertheless, the client will come to us with questions like: - Why didn't you prevent this from happening (thats why we added a startup dbstructure check:cool:) - Can you fix this (yes of course we can try, but that will cost a lot of time, and you don't get any garantees). - Can you garantee that no work has been lost (no ofcourse not... If you hadn't restored a prehistoric database, and the software isn't meant to work with that structure...) I can't inmagine that software packages like Exact, etc don't perform somesort of db check at startup. But maybe I'm to optimistic...

Regards ... OttO

You never got problems that a client updated the software (adding columns and tables) and after a crash restored a database from before the update? How would you prevent this, other than checking the structure?

Regards ... OttO

I suppose that depends upon the type of app, the customer base etc. Our company develops a app for a small group of customers. They yearly pay a fixed perc of the initial prize to get support. If they have additional wishes, they have to pay additional per hour or fixedprice. A new (custom)module is prized the same way: they buy it, normally fixed prize, and the support prize per year rises with the same perc. The prize for the module is based upon investment in resources plus a risk margin and sometimes devided by the number of clients we know that will buy it. I don't know how TotalCommander does it, but they charge only once, and give updates for free. They probably have a very big userbase.

Regards ... OttO

The apps (it is a conglomerate of multiple exes in various versions) accesses the DB via ODBC. The db structure is upgraded for higher versions of the app via an 'upgrade' tool. The tool is kept up to date and recognizes the current version of each apps own tables. It knows to what version the upgrade must be done per app, and knows the steps. It can change the structure, update the content etc. The column type, size, default value, 'null allowed' is checked by the apps at startup. same goes for StoredProcedures, functions and nessecary views. Upgrading SQLServer version hasn't been a major issue in the past. Only some minor differences have been adressed like the change in 'default value'. Users etc are allowed to add indexes, views etc, but they arent allowed to change the apps tables by adding or changing types of columns. Our clients can get twice a year a major build upgrade and in between sometimes a update if nessecary. No client follows the upgrades close by, only on a 'need' basis. Clients use at the moment ca 6 minor/major versions. I get a feeling that not many applications check at startup the structure of the database they use. Is that correct?

Regards ... OttO

my app uses SQLServer 2000,2005 or 2008R2 depending on the client. At the start the app checks the table structure StoredProcedures etc. The description has been stored in XML. All checks are designed for 2000. Few things have been changed to support 2005 etc. Now I want to take advantage of more recent stuff like VarChar(max) instead of TEXT. What is the best way to do this? Easy maintainable and still keep support for the different versions (90% of our clients still use SQLServer 2000). Any tools, tips, tricks in SQLServer or external?

Regards .... OttO