Qbasic cvs problem

[Steve Rossell]

You do not need to convert the FIELD string to a string first, you can let the compiler do it for you by

...
LOCAL FC AS FIELD
...
Z=CVMS((FC))
...

[Michael Mattias]

Z=CVMS((FC))

===>

Z=CVMS((FC))  ' use extra parens to force conversion of value to correct data type
             ' use comment so when I look at this in six months I won't have 
             ' to wonder why I did this; also so if someone else works on this 
             '  program they don't 'help' by taking out the 'superfluous' parens 
             ' and then come whining to me the program doesn't work anymore.

[John Petty]

Gee Micheal wouldn't an experienced programmer like you write a one time conversion of the data. Are you seriously suggesting that any competent programmer would leave the data in the old format and so require your level of documentation? Is that what you are suggesting?

[Michael Mattias]

wouldn't an experienced programmer like you write a one time conversion of the data

Well, the 'conditions' are not stated, but if other programs which read and write that data are still in service, you could not convert that data unless you converted ALL the programs in the application suite... at the same time.

So let's say I have made a good guess about this; that means the new PB program needs to use the CVMS functions in that DLL; that means the param to same must be a string, and if converting it from FIELD to STRING by adding extra parens, I think the comment is a good idea for the reasons stated therein.

MCM

[Arthur Gomide]

> Are you seriously suggesting that any competent programmer would leave the data in the old format and so require your level of documentation?

I think the problem is not about the power of this or that developer - perhaps there is a need to do it this way!

[Manuel Valdes]

Not knowing the backward compatibility issues, or in general the compatibility issues involved in the program conversion, it's quite risky to advise in one sense or the other. If not compatibility problems are present, then I think John is right; it's better to go standard. Also there are precision differences between the IEEE standard and MBF, which may or may not be relevant, depending on the program purpose.

[John Petty]

Well, the 'conditions' are not stated, but if other programs which read and write that data are still in service, you could not convert that data unless you converted ALL the programs in the application suite... at the same time.
MCM

Not really Michael, He has the batch files for the compilation so most likely the BC compiler is present so after the conversion he just has to recompile any other programs without the /MBF option in the batch files and they will work fine.
As the program is done in version 7 if I were Dan I would be more worried as to why it is using the Es option.

[Dan English]

The conditions

Just as a matter of interest (since there seems to be some), the reason we are doing this is money of course! This app is 20 years old, its an accounting and payroll app with customers that are willing to pay to have it converted and upgraded. I know there are many apps out there that can do the job but when customers are willing to pay to keep the look and feel who are we to argue. The first step was cleanup of the QuickBasic code, then convert to PowerBasic CC which was almost done when this CVS issue showed up. Now we will start a re-write in windows keeping the look and feel similar to the old app. The last step will be changing the data base. Thanks again for all the help.

[Michael Mattias]

Not really Michael, He has the batch files for the compilation so most likely the BC compiler is present so after the conversion he just has to recompile any other programs without the /MBF option in the batch files and they will work fine.

Call me old-fashioned, but recompiling and retesting all the programs (you WERE going to retest, right?) sure sounds like converting all the programs.

But now that we have learned this software is installed at multiple user sites.... I don't think I'd bother converting the data.

A, Not all customers will run the conversion in the correct sequence (given enough customers, there will always be one who could mess up a free lunch).

B, For sure they won't run the conversions on the same day, meaning I am now supporting multiple versions, at least for a while.

C, Customers may have written their own "QuickBASIC" or other programs AGAINST that data - eg some extra screens and/or reports - and converting the data breaks those programs. This will not earn you points with your customers. (I am not the only person who complains about "backward incompatibility").

D, for every customer who successfully navigates A, B, and C, there will be at least one who manages to archive the wrong set of programs, the wrong set of data or both... and the day they decide to bring back EITHER ONE BUT NOT BOTH programs and data, you have a total and absolute disaster.

For this application, MBF format sounds real good, forever.

MCM

[John Petty]

Call me old-fashioned, but recompiling and retesting all the programs (you WERE going to retest, right?) sure sounds like converting all the programs.

But now that we have learned this software is installed at multiple user sites.... I don't think I'd bother converting the data.
MCM

Of course you retest on a sample data base, remembering the change I listed didn't change a single line of code in all the actual programs merely a compiler option from back in the days when MS compilers were much more reliable.
You tell us how long you have been programming so from your comments are you saying all your programs still use MBF number formats, very ineficient.
Are you saying you never do a data base upgrade? I have done many (either writing or supervising) including bringing my own early apps from MBF to IEEE.
The more you post the more I begin to understand that your actual experience with more than your own application is rather limited.

[Dan English]

Testing...

Good advice Michael, thankyou. Yes, we are testing many times, actually the code needed to be cleaned up so we recompiled after the cleanup (although some programs could not be compiled - too big and I don't know how the author got them to compile).

I have someone running the original code along side the cleaned up code with the same data (copy it back and forth) to be sure that works.) The next step will be running the same data with the PowerBasic code, compare reports trial balance etc.

We will leave the data alone for now until the windows rewrite is well along. Fortunately we have all the original file layouts so writing conversion programs should be straight forward.

[John Petty]

Good advice Michael, thankyou. Yes, we are testing many times, actually the code needed to be cleaned up so we recompiled after the cleanup (although some programs could not be compiled - too big and I don't know how the author got them to compile).

In properties for BC.exe "Memory" have you given it a good chunk of EMS and XMS memory? I forget which one it uses so give it a few MB of both.

[dean goodman]

CVS issue

I just noticed an issue with CVS as well today. I am trying to convert seismic segy data, and running an older version of the software with PB7 works fine. Can someone else test the CVS issue. The same code in PB9 gives a different result... thanks...

[Michael Mattias]

>The same code in PB9 gives a different result... thanks...

Which code?

Better still, show failing code and provide test data along with expected results.

Or... if you are saying ...

CVS(four byte string) [PB 7] <>  CVS (same four-byte string)[PB 9]

.. then that problem has to go directly to PB support, because either the 7x or 9x CVS function is broken. Of course, you will know which one because you must be testing against known data.

If it's 7x that's broken....

... well, don't bother reporting it because it ain't gonna get fixed. Well, give it a shot, but I'd think the best you could do if 7x is broken is to break down and cry and hope they give you a free or reduced-cost upgrade; but today's related health tip is "Don't hold your breath."

MCM