OK, will look forward to it. I did consider changing the JC precompiler to accept SQL code i.e., EXEC SQL etc but got side tracked as I also wanted to allow for other rdbms systems at some point. This way it would act as a one stop shop for many, even if it isn't me doing the coding. I was allowing for a $SET SQL xxxxx as the first few lines or so to specify what the RDB is to be used. Yes it is in Cobol, but I am more current with that than C although I can make sense of code to a point but I can...
Sorry, got sidetracked again, but this is still on my to-do list. Going to work on it hopefully soon.
You might want to look into the exec SQL syntax you are not processing for such as PREPARE etc to see what dbpre needs to do as mysql/mariab supports these. I am attaching the copy of stockMT.scb (and if I can find the generated stockMT.cbl) as used with the JC pre-processor (which you can find in the GC contrib area for the documentation on it) the code for which is a LOT shorter than the one I am using to pre-test dbpre. Some of the /SQL syntax is to load into prog the layout of a RDB table as...
The brackets and preceding colon is from Micro Soft SQL server, and ditto the rest of rdb syntax used. Going by my 75 year old memory was trying to see what dbpre did with it :) That way, I would hopefully know what needed changes. Ah, okay, i have never used Micro Soft SQL server, that explains it ;) Big grief is that on the .lst and .cob dbpre, is double spacing each source line and that is odd as in Windows each line is ended by a CR,LF combo but for *nix it is only one of them LF, so what is...
The brackets and preceding colon is from Micro Soft SQL server, and ditto the rest of rdb syntax used. Going by my 75 year old memory was trying to see what dbpre did with it :) That way, I would hopefully know what needed changes. Ah, okay, i have never used Micro Soft SQL server, that explains it ;) Big grief is that on the .lst and .cob dbpre, is double spacing each source line and that is odd as in Windows each line is ended by a CR,LF combo but for *nix it is only one of them LF, so what is...
The brackets and preceding colon is from Micro Soft SQL server, and ditto the rest of rdb syntax used. Going by my 75 year old memory was trying to see what dbpre did with it :) That way, I would hopefully know what needed changes. Big grief is that on the .lst and .cob dbpre, is double spacing each source line and that is odd as in Windows each line is ended by a CR,LF combo but for *nix it is only one of them LF, so what is dbpre doing that seems to be the reverse process? I will now go through...
I'm looking at it right now. EXEC SQL INCLUDE has a copybook with the suffix .cpy, dbpre doenst expect that and works only with copybooks without any suffix. I'll try to make that more flexible, so both formats can be used. Comments in your source code are usually written with "*>", one comment line starts only with a single asterik which confuses dbpre. EXEC SQL BEGIN DECLARE SECTION - dbpre doesnt need that, i'll try to make dbpre to ignore that. PREPARE/EXECUTE - dbpe doenst support that right...
I'm looking at it right now. EXEC SQL INCLUDE has a copybook with the suffix .cpy, dbpre doenst expect that and works only with copybooks without any suffix. I'll try to make that more flexible, so both formats can be used. Comments in your source code are usually written with "*>", one comment line starts only with a single asterik which confuses dbpre. EXEC SQL BEGIN DECLARE SECTION - dbpre doesnt need that, i'll try to make dbpre to ignore that. PREPARE/EXECUTE - dbpe doenst support that right...
I'm looking at it right now. EXEC SQL INCLUDE has a copybook with the suffix .cpy, dbpre doenst expect that and works only with copybooks without any suffix. I'll try to make that more flexible, so both formats can be used. Comments in your source code are usually written with "*>", one comment line starts only with a single asterik which confuses dbpre. EXEC SQL BEGIN DECLARE SECTION - dbpre doesnt need that, i'll try to make dbpre to ignore that. Lets see if the next release can handle your source...
Have these reported issues now been fixed for release dated October 2021 ?
Hello Piper, OK thanks for looking at the problem. I have been using SQLite3 but recently started using MySQL and got directed into installing MariaDB instead. Functionally the same but better maintained, I have read. Any how, I'll do some more homework! Thanks, Iain
Hi Ian, sorry for the late reply, just found your post here.. -lmysqlclient might be MySql specific, you have to find out how to compile COBOL programs with MariaDB (sorry, i have never used MariaDB). Maybe searching the GnuCOBOL forum for MariaDB support or asking there for help is a solution https://sourceforge.net/p/gnucobol/discussion/ Your problem is not a problem of using dbpre, it is how to compile and link COBOL programs with GnuCobol and MariaDB. Piper
Hello, I have been trying to use dbpre with Gnu Cobol 3.2.1 and MariaDB (Ubuntu 22.04 laptop) but having a few problems, can someone help me please? Fixes I have used: 1. Mariadb libraries used: sudo apt install libmariadb-dev 2. Edite cobmysqlapi.c changed: cob_procedure_parameters to: cob_procedure_params (otherwise compile errors) 4. To compile cobmysqlapi.c used: gcc -I/usr/include/mariadb -c cobmysqlapi.c 5. Then: gcc dbpre.c -odbpre -O5 -ggdb When trying to compile sample PCTB003B: 1. Copied...
works right out of the box.. thanks..great effort!!
dbpre V0.4 uploaded again
For some unknown reasons all files of release V0.4 were gone. Uploaded them again in a new folder structure and fixed some typos in the documentation.
new folder structure, typos fixed
new folder structure
new folder structure
new folder structure
restored V0.4
Hi Alvaro I see that you haven't had any replies yet. Did you try putting a colon in front of the host variable name - i.e. :CARD-NUMBER ? Best of luck Chris
Hi I am a student at the University of Zaragoza and I am trying to create a COBOL program with SQL I'm having problems using the WHERE clause in dbpre. My code is the following: PGCTB-ACTION SECTION. MAIN-PROCEDURE. ACCEPT CARD-NUMBER. EXEC SQL SELECT pin INTO :PIN-DB FROM mytpv.Usuarios WHERE numTarjeta = CARD-NUMBER END-EXEC. EVALUATE TRUE WHEN DB-OK CONTINUE WHEN OTHER PERFORM DB-STATUS END-EVALUATE DISPLAY PIN-DB. PGCTB-ACTION-EXIT. EXIT. I'm searching for a row in my DB where "numTarjeta" matches...
From your response under the recorded bug - PREPARE and EXECUTE are often used SQL...
Bug confirmed. To be honest, the free format mode is not very well tested, i am still...
Bugs in 0.4 (dbpre-code-14)
When processing a source file that is in free format the following problems appear:...
When processing a source file that is in free format the following problems appear:...
Bugs for free format sources and others
Updated cPCTB004S
Added missing files, fixed now.
Should be fixed now, download a snapshot from the link "Code" above, that "Files"...
cleaning up
cleaning up
V0.4
Added missing parameter block
Bugs in 0.4 (dbpre-code-14)
Problems: 0.4 archive not available under "Files". Having downloaded snapshot from...
Next release of dbpre which includes a bugfix of dbpre.c itself and a new example,...
Edit: Typos
Edit: typos
Updated README.TXT
New example how to handle subroutines
New example how to handle subroutines
bugfix for dbpre.c
Bugfix in dbpre.c
It should be ok now, the main reason for this was to get rid of the poctb prefix...
Is all this now completed? Just got round to playing with it. Now to try and change...
Read Simon's post below, to compile the precompiler you need both GnuCobol and MySql...
No, i haven't tried to get it run using Windows, i am a Linux user. But basically...
I don't see any reason why it shouldn't work :-) ... as long as you have a mysql...
I wish, that dbpre from Gnu Cobol would run on windows 7 with mingw or ms visual...