Good morning,
Currently the c++ code is held as you would expect in normal files Windows
files but the I am looking for a way to move them into a database. If you
have another sugeestion that fits the problem I would gladly hear it.
The problem we have is that every month these 50 quoters need updating, but
for most of the quoters most of the months, the process involves changing the
contents of the tables but not the c++ code.
At the moment programmers are used to update these tables, which is
expensive for the company and boring for the programer. There are plenty of
people within the company who have the knowledge to update the tables but who
have never seen Visual Studio and would not really be interested in learning
it, let alone learning SourceSafe to manage the projects.
So we need a very very simple source code control system, but when there is
a need for chaning the C++ code we have to use programers who obviously want
all the nice feature of Visual Studio.
We know from experience that if we have the data in SQL Server or Access
tables and a Master Folder with the C++ projects and code that the two will
get out of sync, changes will be made to the tables that require changes to
the c++ logic and this will not get done, the wrong versions of the C++ code
will be changed etc.
We tried a project where we created out own programing language which we
stored in Access tables along with the data. The Build button converted our
langauge to C++ and then the C++ compiler is called with a makefile.
Technically this works, but the langauge seems to be too complicated for non
programmers and lacking the features that programmers are used to. However
this is very easy to control, there is one Access database for all the code
and tables. Come "Next month" you just copy the Access database and press the
Build button.
We could change this to just store C++ code in the same way as we store our
own language, but our editor doesn't have intellisense, the build process is
not as slick as it is using Visual Studio and there is no integrated
debugging. So there are risks of people making changes using Visual Studio
and not copying the code back into the Access database.
I am trying to find a way of managing the code and tables in such a way that
four of five people, most of whom are not programmers can update the code or
the tables and never mess it up!
A couple of the tables in each quoter are quite large, full post code (zip
code) lists and vehicle code (about 35,000 entries) lists.
Bye
Ian
> > I am working within an insurance company that uses Visual C++ to generate
> > private car motor quotation programs, there are about 50 of these
[quoted text clipped - 12 lines]
>
> > [...]
Boris - 18 Jun 2008 12:34 GMT
Hi Ian,
> Currently the c++ code is held as you would expect in normal files
> Windows
> files but the I am looking for a way to move them into a database. If you
> have another sugeestion that fits the problem I would gladly hear it.
> [...]
the problem you described exists in many companies in the finance and
insurance industry. The business people know everything about the logic in
quotation programs. But it's the developers who have to implement the
logic somehow. As there are two groups a lot of communication is required,
a lot of work is done twice (as the business people also have to implement
the logic somehow by writing it down in Word documents for example so the
developers know what to implement in C++), the developers and thus the
quotation programs often lack behind as the logic is changed by business
people which forces developers to do the same repetitive steps over and
over again etc.
A solution to this problem are so-called spreadsheet components. Business
people typically don't know Visual Studio but they often know Excel. They
can put the logic of a quotation program into an Excel file, play around
with it and test it without requiring a developer. At some point the logic
in the Excel file needs to be deployed somehow (eg. as a Windows
application with a simple GUI). Developers can now use a spreadsheet
component which loads the Excel file directly. Business people tell them
which cells are the input and the output cells. And developers simply pass
input data to the spreadsheet component and fetch results to be displayed
in the GUI from the output cells. The spreadsheet component loads and
processes the logic in the Excel file automatically - no need to convert
anything to C++ code nor for a developer to understand what's going on
there in detail. And if the logic or the data is changed next month by
business people a developer just needs to replace the Excel file (no
repetitive steps but more time to concentrate on less boring tasks which
really require developer brains as they can't be as easily automated).
As you might have guessed already I've been working in the "spreadsheet
component industry" for some years (that's why the problem you described
sounds very familiar to me :). I won't put here any links but if you are
interested I can contact you via mail and show you some demos. Otherwise
you should find some more information on the Internet if you search for
spreadsheet components.
HTH,
Boris