 |
|
|
The mainlogic is identical on all platforms, it is essentially a pile of APIs and events. I had figured that SCC was the only way, but I thought there might be a better way now-a-days.
Rewriting the mainlogic away from C++ to another meta language is possible, but the question is then what is a nice future proof generic meta language?
To answer the next reply too - we do have a Web API layer already too (and HTML5 apps) - so I guess those platforms that cannot support C++ just have to use the Web API, unless there is a meta language that solves my problem.
Thanx
|
|
|
|
|
|
|
The beauty of a meta language is... you can create your own.
It can also be a pitfall.
Regards ... OttO
modified 2 Mar '12.
|
|
|
|
|
|
|
If users will typically have internet access on their devices, the main logic could be wrapped up as a web service. No need to throw any of that away, just build the interface. If the apps don't need access to things like cameras, email, contacts etc, create a HTML5 web page(s). That way the apps are no more than a pointer to the web pages.
If this isn't an option, the only real commonality is potentially the webservice otherwise SQLite.
"You get that on the big jobs."
|
|
|
|
|
|
|
Richard Brett wrote: but how should I handle the "mainlogic" ?
1. Analyze the existing code
2. Define a limited subset of C++ that allows you implement the existing code. This involves restricting features that currently exist in C++ (such as very limited template use.)
3. If necessary re-write the logic to match the subset of 2.
4. Create translators for the other target languages. Basically cross compilers that translate from 2 to other languages.
5. Add 4 into your build process for the main logic to insure that non-supported features do not creep in.
2/4 can be complex or simple depending on what the code does and what the target languages are.
|
|
|
|
|
|
|
Hello 2 all!
I would like to run or participate in a project of compiler (or, maybe, a translator, or an interpretter). During last months I have gained some skills in this area and would like to enlarge them. Now I started writing a compiler of a C-like language right into the machine code (previously I wrote a translator of a C-like code into MASM, compiled programs worked well, so I do have some background). Though, it will be hard to make it alone, maybe by myself I can gather less clear ideas the compiled language could look like. So I would like to find a partner, or maybe just join some beginning project like mine. Any suggestions?
modified 27 Feb '12.
|
|
|
|
|
|
|
You might be better to post this in the Collaboration / Beta Testing forum.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
Depends on your app and how you access data.
I suspect that in some situations that if you change the structure of a database then you will need to change the app to correctly access it.
If you don't need to do that then no problem. If you do then either you don't make such changes or you will need to provide a value that lets your app know how to vary depending on the structure of your database.
It might be relevant also to keep in mind that someone might upgrade their database server but not update the database structure. Also what do you think will be in the impact of incremental upgrades over time if you keep adding flags to the app?
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
OChristiaanse wrote: I get a feeling that not many applications check at startup the structure of the
database they use
The structure itself? No.
I suspect the majority don't do any validation at all. The app assumes the structure is correct.
Myself I version the database via data to allow runtime checks. But I wouldn't check the schema.
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
OChristiaanse wrote: You never got problems that a client updated the software (adding columns and
tables)
Normally the systems I work on do not allow that. Not sure I have worked on any that did that.
OChristiaanse wrote: and after a crash restored a database from before the update?
If they added them and failed to restore them then that would be their problem.
OChristiaanse wrote: How would you prevent this, other than checking the structure?
I would start by not allowing that in the first place.
The first possible solution to allow for user defined data is to provide a meta data structure in the database, via appropriate tables, rather than allowing users to add their own.
Other than that how do you prevent them from adding something you don't know about? If you don't know about it no solution you come up with will allow you to detect if it is missing.
|
|
|
|
|
|
|
(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 
- 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 )
- 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
|
|
|
|
|
|
|
I'm confused as to what the issue is here. The normal way to solve this issue is to have a decent backup solution implemented on the server. Why is this not appropriate for your problem?
|
|
|
|
|
|
|
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' a few hours later: 'oh no, it doesn't work'
Backup's aren't the problem. Stupid users and ignorant developers are.
Regards ... OttO
|
|
|
|
|
|
|
But you talked about the user recovering from a catastrophic database failure by reinstalling the database. That is not the way out of the problem. Being able to seamlessly recover from a backup is the way to bypass this issue.
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
Ahh, I see what you're getting at. What we do is have a version table in the database which we query to determine whether or not the latest version is installed. This table is kept up to date by the installation scripts and the version must match the version number we keep in the application configuration.
|
|
|
|
|
|
|
|
|
|
We have a custom data provider that sits at the back end that allows us to swap between the vendors. We can't use something like nhibernate because we switch between different geo functionality between database vendors. This wraps up a lot of the standard geocoding stuff for us.
|
|
|
|
|
|
|
Thanks for the info.
Regards ... OttO
|
|
|
|
|
|
|
No problem. Glad to help.
|
|
|
|
|
|
|
OChristiaanse wrote: 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.
I solve that all the time.
I have a table like: db_version.
It has columns like: name and version.
Name is a text value.
Version has a format like {number}.{number}.{number} (text too)
A software 'update' that applies a database update adds one or more rows to that table.
Software that uses the database either relies on a specific name/version pair or it relies on a minimum name/version pair.
When the software starts it validate the match or minimal versions that it expects.
If they don't match then the software issues an error and exits.
The name column exists to allow sub functional dependency checks rather than just a global version.
|
|
|
|
|
|
|
Thanks, your extra vote no.2 for this approach.
Regards ... OttO
|
|
|
|
|
|
|
databinding between WPF and sqlserver 2008 express
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin