Gendbc - produces incomplete program

[Alan Pengelly]

I have had a first go at using GenDBC (with
VFP9), supposedly as per help instructions.

I have also had a search through archive newsgroup
stuff (I keep tons of stuff like this, sad isn't
it)

command line is:
set Default to d:\TestOpen
* open project database
OPEN DATABASE ;
D:\Fox9\PJX\opens\opensdata\opens.dbc
* set to current
SET DATABASE TO OPENS
* Do GenDBC
DO HOME()+'tools\gendbc\gendbc' ;
WITH "D:\TestOpen\opendb.prg"
* Creates opendb.prg and .krt files
DO opendb
Creates empty database, no tables, views or stored
procedures. Ran without error.

Running opendb.prg predictably produces error
maketable_TableName.prg does not exist.

It produces the code below. What am I doing wrong,
or have I the wrong version or something?

**** start opendb.prg
* * 28/10/2005 OPENS.DBC 17:44:17
* * Description:
* * This program was automatically generated by
* * GENDBC
* * Version 2.26.67
**************************************************

DisplayStatus([Creating database...])
CLOSE DATA ALL
CREATE DATABASE 'OPENS.DBC'
DisplayStatus([Creating table PLAYERS...])
MakeTable_PLAYERS()
*** remove similar lines
DisplayStatus([Creating view VOPENCOMPS...])
MakeView_VOPENCOMPS()
DisplayStatus([Finished.])


FUNCTION DisplayStatus(lcMessage)
WAIT WINDOW NOWAIT lcMessage
ENDFUNC
********** ends prg

regards
Alan

[Cindy Winegarden]

Hi Alan,

Does this work for you? I get about 1653 lines of code:
Open Database ;
"C:\Program Files\Microsoft Visual FoxPro
9\Samples\Northwind\Northwind.DBC"
DO HOME()+'tools\gendbc\gendbc' ;
WITH "TestDBC.prg"
Modify Command TestDBC

By the way, GoogleGroups (groups.google.com) is a great archive of
newsgroups. No need to save everything locally!
--
Cindy Winegarden MCSD, Microsoft Visual FoxPro MVP
***@msn.com www.cindywinegarden.com
Blog: http://spaces.msn.com/members/cindywinegarden

Post by Alan Pengelly
I have had a first go at using GenDBC (with
VFP9), supposedly as per help instructions.
I have also had a search through archive newsgroup
stuff (I keep tons of stuff like this, sad isn't
it)
It produces the code below. What am I doing wrong,
or have I the wrong version or something?

[Alan Pengelly]

Hi Cindy,

Post by Cindy Winegarden
Does this work for you?

'fraid not, but TFTR.

Just 99 lines of code. The only change I made to
your code was to alter part of the path to the
Northwind database
from "Microsoft Visual FoxPro 9"
to "VFP9"
in order to identify it correctly on my
installation.

"C:\Program Files\Microsoft Visual FoxPro
9\Samples\Northwind\Northwind.DBC"

regards
Alan

[Cindy Winegarden]

Hi Alan,

Have you considered getting a fresh copy of it off your VFP install CD? Have
you tried putting the data and GenDBC in the same directory?
--
Cindy Winegarden MCSD, Microsoft Visual FoxPro MVP
***@msn.com www.cindywinegarden.com
Blog: http://spaces.msn.com/members/cindywinegarden

Post by Alan Pengelly
Hi Cindy,

Post by Cindy Winegarden
Does this work for you?

'fraid not, but TFTR.....

[Alan Pengelly]

In article

*Date:* Mon, 31 Oct 2005 16:25:28 -0500
Hi Alan,
Have you considered getting a fresh copy of it
off your VFP install CD? Have you tried putting
the data and GenDBC in the same directory?

Tried both of these, still no different.

regards
Alan

[Olaf Doschke]

1. If you start GENDBC without any database open, you get an OpenFile-Dialog.
That should be easier, as gendbc then can do one thing: it can open the
database exclusively. It may also do so, if the database is already open, by
closing it and reopening it, but there is a COMPILE DATABASE that can
only run, if the database is opened exclusive. You may comment out that part,
as the database should be compiled anyway.

2. Starting the prg generated by gendbc creates the database in the curdir(), so
set that to an empty new folder, CD to that folder, put PRG and KRT file in
it and start the PRG.

Bye, Olaf.

[Alan Pengelly]

Olaf,

Thanks for your assistance but ...

Post by Olaf Doschke
1. If you start GENDBC without any database
open, you get an OpenFile-Dialog.
That should be easier, as gendbc then can do
one thing: it can open the
database exclusively. It may also do so, if the
database is already open, by
closing it and reopening it, but there is a
COMPILE DATABASE that can
only run, if the database is opened exclusive.
You may comment out that part,
as the database should be compiled anyway.

Copying everything DBC, tables etc and gendbc.prg
copied from VFP9 CD to a fresh folder.

Running it on it's own and going via the openfile
dialogue gives messagebox titled "Aborting GenDBC"
and the error "Unrecoverable error. The database
must be opened exclusively at line 289." ...

Post by Olaf Doschke
2. Starting the prg generated by gendbc creates
the database in the curdir(), so
set that to an empty new folder, CD to that
folder, put PRG and KRT file in
it and start the PRG.

I don't get that far. The program contains lines
calling procedures that are not there.

There is a single function:
**** cut and
FUNCTION DisplayStatus(lcMessage)
WAIT WINDOW NOWAIT lcMessage
ENDFUNC
**** pasted

and many lines similar to
***** cut
DisplayStatus([Creating table THISCLUB...])
MakeTable_THISCLUB()
***** and pasted

It's the MakeTable_name/view/connection
procedures that are not being sent to the
specified prg

It would appear that this is the latest version
the last of the version info is below.

** 9.0 - Changes/Fixes
** 2004.03.19 DH Added support for Blob,
VarChar, and VarBinary fields
** 2004.04.14 DH Added support for
AllowSimultaneousFetch,
** RuleExpression, and RuleText
properties for views


regards
Alan

[Olaf Doschke]

Hi Alan,

Post by Alan Pengelly
Running it on it's own and going via the openfile
dialogue gives messagebox titled "Aborting GenDBC"
and the error "Unrecoverable error. The database
must be opened exclusively at line 289." ...

Okay, I didn't make it obvious enough:
GENDBC.PRG tries to open the DBC exclusive and
of course fails, if it can't do that. The error message
does not state, that the line 289 is false, but that it
can't open the database exclusive, that's all.

So you have to modify the prg to work with
open DBCs:
Replace every EXCLUSIVE with SHARED in the
gendbc.prg and comment the line (I assume line 290):

COMPILE DATABASE (m.g_cFullDatabase)
=>
* COMPILE DATABASE (m.g_cFullDatabase)

THEN you can run gendbc on open DBCs too.

There is no problem, as the compile should not be
neccessary, or you would have a problem with the
DBC anyway, so that is obsolete. It's even dangerous to
run that line, if using a newer VFP version than the
version, which created/compiled the DBC originally.

And a DBC open shared cannot change it's structure,
so it is also no danger, that the database could change
during it's analysis by gendbc...

Bye, Olaf.

[Alan Pengelly]

Olaf,
Sorry if I'm appearing a bit simple.

Post by Olaf Doschke
Replace every EXCLUSIVE with SHARED in the
gendbc.prg and comment the line (I assume line
COMPILE DATABASE (m.g_cFullDatabase)
=>
* COMPILE DATABASE (m.g_cFullDatabase)

OK, done these. although I had already tried
opening the DB exclusive.

Post by Olaf Doschke
THEN you can run gendbc on open DBCs too.
And a DBC open shared cannot change it's
structure,
so it is also no danger, that the database
could change
during it's analysis by gendbc...

Very good point.

However we may be getting slightly off the point.
I had actually managed to get it to run *before*
contacting the group, but it produced incomplete
code, without errors being reported.

As I said in my original post, even following your
worthwhile modification to the program and
creating an empty folder with only gendbc.prg and
.krt files in it produces only an empty database,
without even the stored procedures from the krt
file.

Cindy Winegarden tried it on the northwind
database to produce 1600+ lines of code, on my
machine it produced 90+ lines. The
MakeTable_Table/ViewEtc procedures are missing.

It looks like I will have to either google for a
later version or SET STEP ON and crawl through it
and find the fault. It's usually my fault in the
end. :-) Even after 20 years with fox! I was
hoping for a brain pain free solution.

Thanks very much for your time.

regards
Alan

[Dan Freeman]

The .KRT files are just .txt files that contain the stored procs from the
database being documented. You don't need to haul those around.

Something really weird is going on here. I've never seen anything like this
reported from gendbc.

Dan

Post by Alan Pengelly
Olaf,
Sorry if I'm appearing a bit simple.

Post by Olaf Doschke
Replace every EXCLUSIVE with SHARED in the
gendbc.prg and comment the line (I assume line
COMPILE DATABASE (m.g_cFullDatabase)
=>
* COMPILE DATABASE (m.g_cFullDatabase)

OK, done these. although I had already tried
opening the DB exclusive.

Post by Olaf Doschke
THEN you can run gendbc on open DBCs too.
And a DBC open shared cannot change it's
structure,
so it is also no danger, that the database
could change
during it's analysis by gendbc...

Very good point.
However we may be getting slightly off the point.
I had actually managed to get it to run *before*
contacting the group, but it produced incomplete
code, without errors being reported.
As I said in my original post, even following your
worthwhile modification to the program and
creating an empty folder with only gendbc.prg and
.krt files in it produces only an empty database,
without even the stored procedures from the krt
file.
Cindy Winegarden tried it on the northwind
database to produce 1600+ lines of code, on my
machine it produced 90+ lines. The
MakeTable_Table/ViewEtc procedures are missing.
It looks like I will have to either google for a
later version or SET STEP ON and crawl through it
and find the fault. It's usually my fault in the
end. :-) Even after 20 years with fox! I was
hoping for a brain pain free solution.
Thanks very much for your time.
regards
Alan

[Olaf Doschke]

Hi Alan,

Maybe give gendbcx.prg a try.

ftp://ftp.prolib.de/Public/VFP/Gendbcx.zip

same modifications regarding exclusive can
be applied...

Bye, Olaf.

[Alan Pengelly]

Hi Olaf,

Post by Olaf Doschke
Maybe give gendbcx.prg a try.
ftp://ftp.prolib.de/Public/VFP/Gendbcx.zip

Amazing, thanks VERY much, worked right out of the
box! Over 1000 lines of code. File dated
13Dec1997. Cannot (so far) find a later version -
even on the site recommended in the docs

Post by Olaf Doschke
http://www.stevearnott.com/

A bit bare there.

Stored procs is empty, and there was a non-fatal
error messagebox saying it didn't cope with
filters on primary keys, but would add a note,
(which I haven't found yet).

Adding back the stored procedures contained in the
KRT file will be no problem. But I wasn't aware I
had put a filter on a primary key! I'll have to
check THAT out.

Many thanks again. As Dan said ... weird.

regards
Alan

[Olaf Doschke]

Post by Alan Pengelly

Post by Olaf Doschke
http://www.stevearnott.com/

A bit bare there.

Yes, I noticed that too.

gendbcx seems to have no owner/maintainer
anymore.

Ed Leafe is hosting a download dated 1997-12-14
at http://leafe.com/dls/vfp (the very last download
at the bottom of that page). Maybe Alan fixed
an error in that, which the 1997-12-13 version
had... :-).

Unfortunately gendbcx has no support for new
vfp9 field types and so an update would be very
welcome.

Maybe within the SednaX project???
http://codegallery.gotdotnet.com/sednax

Bye, Olaf.

[PM Godfrey]

For the most recent version I can find, visit:
<http://leafe.com/dls/vfp>

Although the entire page is worth reviewing, go to the bottom of the
page to locate GENDBCX.prg



On Thu, 3 Nov 2005 16:36:43 +0000 (UTC),

Post by Alan Pengelly
Hi Olaf,

Post by Olaf Doschke
Maybe give gendbcx.prg a try.
ftp://ftp.prolib.de/Public/VFP/Gendbcx.zip

Amazing, thanks VERY much, worked right out of the
box! Over 1000 lines of code. File dated
13Dec1997. Cannot (so far) find a later version -
even on the site recommended in the docs

Post by Olaf Doschke
http://www.stevearnott.com/

A bit bare there.
Stored procs is empty, and there was a non-fatal
error messagebox saying it didn't cope with
filters on primary keys, but would add a note,
(which I haven't found yet).
Adding back the stored procedures contained in the
KRT file will be no problem. But I wasn't aware I
had put a filter on a primary key! I'll have to
check THAT out.
Many thanks again. As Dan said ... weird.
regards
Alan

[Alan Pengelly]

Thanks for everyone's suggestions. I
eventually decided against using gendbx because
the latest gendbc can handle VFP8/9 new field
types etc.

I spent a laborious Saturday afternoon after golf
(how sad is this) and eventually resolved the
problem.

I eventually realised that the program was trying
to add sections of code to a single memo field,
which then became the generated code. Only the
first was being updated. The original creation of
the table has an "APPEND BLANK"

I develop with the default setting of optimistic
locking. The problem went away with the addition
(somewhat crude I know) of inserting of one line
of code.

=TABLEUPDATE()

immediately after each occurrence of the line

APPEND MEMO aProgram FROM "GenDBC.tmp"

All the tables are correctly created (cursory
check), with their last browse settings intact.

Now to find out why the stored procedures are not
added from the .krt file, or even if this is
possible. <sigh>

*Date:* Fri, 04 Nov 2005 09:27:55 -0500
<http://leafe.com/dls/vfp>
Although the entire page is worth reviewing, go
to the bottom of the
page to locate GENDBCX.prg
On Thu, 3 Nov 2005 16:36:43 +0000 (UTC),

Post by Alan Pengelly
Hi Olaf,

Post by Olaf Doschke
Maybe give gendbcx.prg a try.
ftp://ftp.prolib.de/Public/VFP/Gendbcx.zip

Amazing, thanks VERY much, worked right out of

the >box! Over 1000 lines of code. File dated

Post by Alan Pengelly
13Dec1997. Cannot (so far) find a later

version - >even on the site recommended in the
docs

Post by Alan Pengelly

Post by Olaf Doschke
http://www.stevearnott.com/

A bit bare there.
Stored procs is empty, and there was a

non-fatal >error messagebox saying it didn't
cope with >filters on primary keys, but would
add a note, >(which I haven't found yet).

Post by Alan Pengelly
Adding back the stored procedures contained in

the >KRT file will be no problem. But I wasn't
aware I >had put a filter on a primary key!
I'll have to >check THAT out.

Post by Alan Pengelly
Many thanks again. As Dan said ... weird.