Question about coding for dbf and sql

[Ian]

Hi all,

I am re-writing my apps to bring them more up to date. I have decided
to re-write the whole lot as there is a lot of old and bad code in the
current version that I want to get rid of. I am writing the new one as
a dbf/cdx system with a view that I will produce an sql version at a
later date.

I am doing the dbf/cdx first as I am familiar with that code and most
of my customers wont move to sql but I still need amore up to date and
more compact version of the current system hence the rewrite.

To try and make the move to sql easier I have created my window so it
does not create the access/assign methods. I am then accessing the
sle's on the window using fieldget and fieldput. My question is this,
am I right to stop the window generating acess and assigns and am I
write to use fieldget and fieldput from the start if I want to move
the code to sql at a later date.

Second question is I have seen a lot about not using the dbserver
editor as it should be avoided if moving to sql at a later stage. How
do you actually get your servers without using the dbserver editor.

I know I am doing twice the work dbf and sql but I have to do a dbf
version update for some customers (hence the complete re-write) but I
want to make sure the re-write I am doing is done in a way that makes
the later move to sql as easy as it can be.

Any help would be appreciated.

Regards,
Ian

[Paul D B]

Post by Ian
Hi all,
I am re-writing my apps to bring them more up to date. I have decided
to re-write the whole lot as there is a lot of old and bad code in the
current version that I want to get rid of. I am writing the new one as
a dbf/cdx system with a view that I will produce an sql version at a
later date.
I am doing the dbf/cdx first as I am familiar with that code and most
of my customers wont move to sql but I still need amore up to date and
more compact version of the current system hence the rewrite.
To try and make the move to sql easier I have created my window so it
does not create the access/assign methods. I am then accessing the
sle's on the window using fieldget and fieldput. My question is this,
am I right to stop the window generating acess and assigns and am I
write to use fieldget and fieldput from the start if I want to move
the code to sql at a later date.
Second question is I have seen a lot about not using the dbserver
editor as it should be avoided if moving to sql at a later stage. How
do you actually get your servers without using the dbserver editor.
I know I am doing twice the work dbf and sql but I have to do a dbf
version update for some customers (hence the complete re-write) but I
want to make sure the re-write I am doing is done in a way that makes
the later move to sql as easy as it can be.
Any help would be appreciated.
Regards,
Ian

Hi Ian,

I don't use access/assigns in the window editor
I don't use DB server Editor.

You just create you DBF's and indexes with any DBF tool (for instance
DBALite, DBAdmin).

Once you've got a DBF you can open it in your application.
I always put the server in a variable of the window class so you can
access it from within every method of your window:

CLASS LiterPrijsWin INHERIT NewDataWindow

//{{%UC%}} USER CODE STARTS HERE (do NOT remove this line)

PROTECT oDBLiterPr AS PDBServer

Then in your postinit() (or whatever method):

SELF:oDBLiterPr := DBServer{"LITERPR.DBF"}



SELF:oDBLiterPr:SetIndex("LITERPR")

SELF:oDBLiterPr:SetOrder("LITERPR01")


When reading/writing to the table, use Fieldput/Fieldget, like:
SELF:oDBLiterPr:FIELDPUT( #LPInfo,
AllTrim(SELF:oDCmleLPInfo:textvalue) )

When using VO2ADO, this stays exactly the same syntax.

HTH

[Ian]

Post by Paul D B

Post by Ian
Hi all,
I am re-writing my apps to bring them more up to date. I have decided
to re-write the whole lot as there is a lot of old and bad code in the
current version that I want to get rid of. I am writing the new one as
a dbf/cdx system with a view that I will produce an sql version at a
later date.
I am doing the dbf/cdx first as I am familiar with that code and most
of my customers wont move to sql but I still need amore up to date and
more compact version of the current system hence the rewrite.
To try and make the move to sql easier I have created my window so it
does not create the access/assign methods. I am then accessing the
sle's on the window using fieldget and fieldput. My question is this,
am I right to stop the window generating acess and assigns and am I
write to use fieldget and fieldput from the start if I want to move
the code to sql at a later date.
Second question is I have seen a lot about not using the dbserver
editor as it should be avoided if moving to sql at a later stage. How
do you actually get your servers without using the dbserver editor.
I know I am doing twice the work dbf and sql but I have to do a dbf
version update for some customers (hence the complete re-write) but I
want to make sure the re-write I am doing is done in a way that makes
the later move to sql as easy as it can be.
Any help would be appreciated.
Regards,
Ian

Hi Ian,
I don't use access/assigns in the window editor
I don't use DB server Editor.
You just create you DBF's and indexes with any DBF tool (for instance
DBALite, DBAdmin).
Once you've got a DBF you can open it in your application.
I always put the server in a variable of the window class so you can
CLASS LiterPrijsWin INHERIT NewDataWindow
//{{%UC%}} USER CODE STARTS HERE (do NOT remove this line)
PROTECT oDBLiterPr AS PDBServer
SELF:oDBLiterPr := DBServer{"LITERPR.DBF"}
SELF:oDBLiterPr:SetIndex("LITERPR")
SELF:oDBLiterPr:SetOrder("LITERPR01")
SELF:oDBLiterPr:FIELDPUT( #LPInfo,
AllTrim(SELF:oDCmleLPInfo:textvalue) )
When using VO2ADO, this stays exactly the same syntax.
HTH
--
Paul- Hide quoted text -
- Show quoted text -

Hi Paul,

Thanks for the reply. Looks like I am going in the right direction. I
have decided to use VO2ADO for the sql version so I am happy that you
say the code stays the same with VO2ADO. Hopefully I might be able to
progress this now.

Thanks a lot

Ian

[Williem]

Ian,

I use VO2ADO for my SQL projects. The I also do not use access/assign
for the fieldgets/puts. What I do is a simple scatter/gather logic.

I have subclassed the ADORecordset class to add skip/append/eof/
fieldget/feildput and a few other methods. I use the ADORecordset for
everything except bbrowser. I need ADOServer for that. but by adding
the few extra methods to the subclass, the code looks very similar to
the DBF version.

Geoff has a set of classes that further abstracts the process so the
DBF code can run with almost no changes. you might want to contact him
about that.

Regards,

Willie

[r***@googlemail.com]

hi

we use a data dictionary

METHOD Init() CLASS DataStruct
LOCAL aTemp:={} AS ARRAY
LOCAL n AS WORD
LOCAL lICUnique AS LOGIC

// Get Parameters affecting Indexes // Set at start of DoCheck3()
lICUnique:=SysObject():GetParam(ICNoUnique)

// Create Reports Files array
SUPER:Init()

// Create Structure Array
SELF:aDataStruct:=ArrayNew(Len(aDataFiles),5) // sFilePath&Name,
sTitle, aDBFStructure, aCDXStructure, lHasFPT, lHasPatch

// Collect data from aDataFiles
FOR n = 1 TO Len(aDataFiles)
aTemp:=aDataFiles[n]
aDataStruct[n,FilePathName]:=aTemp[FilePathName]
aDataStruct[n,Title]:=aTemp[Title]
NEXT

// Complete with structure details
// DOCAC ***********************************
aDataStruct[FileDOCAC,DBFStructure]:= { ;
{ 'JOBNO' , 'C', 8, 0}, ;
{ 'GROUP' , 'C', 8, 0}, ;
{ 'VALUE' , 'N', 9, 0}, ;
{ 'RISK' , 'C', 1, 0}, ; // P only
{ 'RECORDDATE' , 'D', 8, 0}, ;
{ 'COMMENT' , 'C', 80, 0}, ;
{ 'STARTDATE' , 'D', 8, 0}, ;
{ 'ENDDATE' , 'D', 8, 0}, ;
{ 'STARTCODE' , 'C', 1, 0}, ;
{ 'ENDCODE' , 'C', 1, 0}, ;
{ 'RECORDTYPE' , 'C', 1, 0}, ; // I nstruction, B udget,
P roposal
{ 'DOCREF' , 'C', 15, 0}, ; // for linking docs
together
{ 'DOCNO' , 'C', 15, 0}}

aDataStruct[FileDOCAC,CDXStructure]:= { ;
{'DOCAC1','JobNo + Group + Docno',{|| _FIELD->JobNo + _FIELD->Group
+ _FIELD->DocNo}, NIL, NIL} }

aDataStruct[FileDOCAC,HasFPT]:=FALSE

// DOCAD *********************************** reviewed 070501


thats for a start.... 60 tables

then we have a set of code that
a) checks the tables and index's exist - so ok to proceed
b) in the admin module checks the structure we need is fine, allows
uswers to add more fields and index's

and then we pass the array of table names to report pro designer

r

[Ian]

Post by Williem
Ian,
I use VO2ADO for my SQL projects. The I also do not use access/assign
for the fieldgets/puts. What I do is a simple scatter/gather logic.
I have subclassed the ADORecordset class to add skip/append/eof/
fieldget/feildput and a few other methods. I use the ADORecordset for
everything except bbrowser. I need ADOServer for that. but by adding
the few extra methods to the subclass, the code looks very similar to
the DBF version.
Geoff has a set of classes that further abstracts the process so the
DBF code can run with almost no changes. you might want to contact him
about that.
Regards,
Willie

Hi Willie,

I got some data from Geoff a while ago when I started thinking about
sql. Then after looking closely at my code I realised there a was a
lot of wastage and doubling up of methods as well as a lot of
redundant or bad code.

I therefore decided that the best course of action was not to try and
use what I had but to re-write the whole app in a more structured way
that would then make the move to sql easier at that point.

I have done the basic bones of a window for customer accounts, lookups
and reports and I am now looking at the methods for these and how they
should be written to maximise the dbf version to its full, but to also
make the sql conversion easier when I get to that stage.

My aim is to get this small part of the app complete as a dbf system
and then reuse as much as possible of that for the sql version. Other
than the tables I am hoping the window layouts and methods would be
right for both formats DBF and SQL, or am I being a bit naive.

So I think scrapping the access/assign methodology is best and I
should start to use fieldget/fieldput and I also need to stop using
the dbserver editor. If I stop using the dbserver editor you can not
set a server in the window editor so I need to sort that out. I also
beleive I need to stop using dbusearea and the like and make more use
of oServer.

Noty trying to rush this but hoping to avoid doing a complete rewrite
only to find I've still made it harder than it should be to convert to
sql.

Any assist will be gratefully received.

Ian

[Graham McKechnie]

Ian,

If you are going to re write your application and move to Sql, now is a very
good time to consider moving it to .Net and C#. You will have to do it
sooner or later, so why not start now, otherwise you'll be looking at a
second re write.

If Sql is new to you, you'd be far better off doing it with .Net than taking
your dbf baggage with you. No matter how you look at it, dbf and sql really
don't marry up too well, so you are better off learning Sql from a .Net
point of view and dropping your dbf way of thinking.

You have the advantage of the fact that there are absolutely heaps of
resources available to you - tutorials, books etc for Sql and .Net, as
compared to the very limited information available via VO2ADO and Geoff's
classes etc.

Graham

Post by Ian

Post by Williem
Ian,
I use VO2ADO for my SQL projects. The I also do not use access/assign
for the fieldgets/puts. What I do is a simple scatter/gather logic.
I have subclassed the ADORecordset class to add skip/append/eof/
fieldget/feildput and a few other methods. I use the ADORecordset for
everything except bbrowser. I need ADOServer for that. but by adding
the few extra methods to the subclass, the code looks very similar to
the DBF version.
Geoff has a set of classes that further abstracts the process so the
DBF code can run with almost no changes. you might want to contact him
about that.
Regards,
Willie

Hi Willie,
I got some data from Geoff a while ago when I started thinking about
sql. Then after looking closely at my code I realised there a was a
lot of wastage and doubling up of methods as well as a lot of
redundant or bad code.
I therefore decided that the best course of action was not to try and
use what I had but to re-write the whole app in a more structured way
that would then make the move to sql easier at that point.
I have done the basic bones of a window for customer accounts, lookups
and reports and I am now looking at the methods for these and how they
should be written to maximise the dbf version to its full, but to also
make the sql conversion easier when I get to that stage.
My aim is to get this small part of the app complete as a dbf system
and then reuse as much as possible of that for the sql version. Other
than the tables I am hoping the window layouts and methods would be
right for both formats DBF and SQL, or am I being a bit naive.
So I think scrapping the access/assign methodology is best and I
should start to use fieldget/fieldput and I also need to stop using
the dbserver editor. If I stop using the dbserver editor you can not
set a server in the window editor so I need to sort that out. I also
beleive I need to stop using dbusearea and the like and make more use
of oServer.
Noty trying to rush this but hoping to avoid doing a complete rewrite
only to find I've still made it harder than it should be to convert to
sql.
Any assist will be gratefully received.
Ian

[Geoff Schaller]

Sql, SQL and SQL...

Get the picture <g>.

But don't scrap the server classes with their accesses and assigns. We
have a small code generator written in VO to open a DBF and its indexes
and build strongly typed classes to use in your code. DBF or SQL.

Honestly, using Fieldput and get etc just invites code bugs and
maintenance problems for the future. Having that right-click
availability of field names also speeds up code design and makes your
code far more portable to C# or ADO.Net.

Geoff

Post by Ian

Post by Williem
Ian,
I use VO2ADO for my SQL projects. The I also do not use access/assign
for the fieldgets/puts. What I do is a simple scatter/gather logic.
I have subclassed the ADORecordset class to add skip/append/eof/
fieldget/feildput and a few other methods. I use the ADORecordset for
everything except bbrowser. I need ADOServer for that. but by adding
the few extra methods to the subclass, the code looks very similar to
the DBF version.
Geoff has a set of classes that further abstracts the process so the
DBF code can run with almost no changes. you might want to contact him
about that.
Regards,
Willie

Hi Willie,
I got some data from Geoff a while ago when I started thinking about
sql. Then after looking closely at my code I realised there a was a
lot of wastage and doubling up of methods as well as a lot of
redundant or bad code.
I therefore decided that the best course of action was not to try and
use what I had but to re-write the whole app in a more structured way
that would then make the move to sql easier at that point.
I have done the basic bones of a window for customer accounts, lookups
and reports and I am now looking at the methods for these and how they
should be written to maximise the dbf version to its full, but to also
make the sql conversion easier when I get to that stage.
My aim is to get this small part of the app complete as a dbf system
and then reuse as much as possible of that for the sql version. Other
than the tables I am hoping the window layouts and methods would be
right for both formats DBF and SQL, or am I being a bit naive.
So I think scrapping the access/assign methodology is best and I
should start to use fieldget/fieldput and I also need to stop using
the dbserver editor. If I stop using the dbserver editor you can not
set a server in the window editor so I need to sort that out. I also
beleive I need to stop using dbusearea and the like and make more use
of oServer.
Noty trying to rush this but hoping to avoid doing a complete rewrite
only to find I've still made it harder than it should be to convert to
sql.
Any assist will be gratefully received.
Ian

[Ian]

Post by Geoff Schaller
Sql, SQL and SQL...
Get the picture <g>.
But don't scrap the server classes with their accesses and assigns. We
have a small code generator written in VO to open a DBF and its indexes
and build strongly typed classes to use in your code. DBF or SQL.
Honestly, using Fieldput and get etc just invites code bugs and
maintenance problems for the future. Having that right-click
availability of field names also speeds up code design and makes your
code far more portable to C# or ADO.Net.
Geoff

Post by Ian

Post by Williem
Ian,
I use VO2ADO for my SQL projects. The I also do not use access/assign
for the fieldgets/puts. What I do is a simple scatter/gather logic.
I have subclassed the ADORecordset class to add skip/append/eof/
fieldget/feildput and a few other methods. I use the ADORecordset for
everything except bbrowser. I need ADOServer for that. but by adding
the few extra methods to the subclass, the code looks very similar to
the DBF version.
Geoff has a set of classes that further abstracts the process so the
DBF code can run with almost no changes. you might want to contact him
about that.
Regards,
Willie

Hi Willie,
I got some data from Geoff a while ago when I started thinking about
sql. Then after looking closely at my code I realised there a was a
lot of wastage and doubling up of methods as well as a lot of
redundant or bad code.
I therefore decided that the best course of action was not to try and
use what I had but to re-write the whole app in a more structured way
that would then make the move to sql easier at that point.
I have done the basic bones of a window for customer accounts, lookups
and reports and I am now looking at the methods for these and how they
should be written to maximise the dbf version to its full, but to also
make the sql conversion easier when I get to that stage.
My aim is to get this small part of the app complete as a dbf system
and then reuse as much as possible of that for the sql version. Other
than the tables I am hoping the window layouts and methods would be
right for both formats DBF and SQL, or am I being a bit naive.
So I think scrapping the access/assign methodology is best and I
should start to use fieldget/fieldput and I also need to stop using
the dbserver editor. If I stop using the dbserver editor you can not
set a server in the window editor so I need to sort that out. I also
beleive I need to stop using dbusearea and the like and make more use
of oServer.
Noty trying to rush this but hoping to avoid doing a complete rewrite
only to find I've still made it harder than it should be to convert to
sql.
Any assist will be gratefully received.
Ian- Hide quoted text -

- Show quoted text -

Hi Geoff,

Are you saying that I should continue to use the dbserver editor. Are
you also saying that I should keep the access/assign on my widnow
controls and not use fieldget/fieldput.

I am a bit confused as some of your papers I have downloaded say I
should get rid of access/assign and use fieldget/fieldput. have I
misunderstood you somewhere or am I reading old data.

What is this code generator that you mention and how do I get hold of
it. Will these strongly typed classes be ok for a dbf or and sql
system or do I still need to sets of server classes one for each.

I am a bit confused So could you answer the following please

Do I still keep using the dbserver editor yes or no ?

Do I keep the access/assign on my window controls yes or no ?

Do I forget about using fieldput/fieldget yes or no ?

Regards,
Ian

[Paul D B]

Post by Geoff Schaller
Honestly, using Fieldput and get etc just invites code bugs and
maintenance problems for the future. Having that right-click
availability of field names also speeds up code design and makes your
code far more portable to C# or ADO.Net.

Geoff,
Fieldget/fieldput introducing code bugs?
And you wouldn't have these when using the DBserver generated accessors,
that are nothing else than fieldgets and fieldputs? Please explain.

@Ian: what I forgot: when dumping DBserver editor, you will also loose
the overhead of all those fieldspecs. If you need fieldspecs, for
instance in the WED for your edit controls , then it is IMO more
interesting to make a small library with the must common fieldspecs
(e.g. a date field, a logic field, some char fields in various lengths
etc etc..).

[Geoff Schaller]

Paul,

Post by Paul D B
Fieldget/fieldput introducing code bugs?

Very simple.

cMyVar := oServer:Fieldget(#MyField)

* No type checking
* No compile time checking
* No warning when someone removes or changes the field
* No inkling anything's wrong until you runtime actually executes this
specific chunk.

So when you want to remove or rename the field it can be quite an issue,
especially if the field name is used in more than one table. Same goes
for using the field. If you make a data type mistake, you can't know
about it until that little bit of code is executed. These can be time
bombs.

So, read my post again and the sample code supplied. That is the
approach I recommend.

Geoff

[Paul D B]

Post by Geoff Schaller
Paul,

Post by Paul D B
Fieldget/fieldput introducing code bugs?

Very simple.
cMyVar := oServer:Fieldget(#MyField)
* No type checking
* No compile time checking
* No warning when someone removes or changes the field
* No inkling anything's wrong until you runtime actually executes this
specific chunk.
So when you want to remove or rename the field it can be quite an
issue, especially if the field name is used in more than one table.
Same goes for using the field. If you make a data type mistake, you
can't know about it until that little bit of code is executed. These
can be time bombs.
So, read my post again and the sample code supplied. That is the
approach I recommend.
Geoff

Geoff, what sample code? There wasn't any. (I read your post again, btw)
you said:
[But don't scrap the server classes with their accesses and assigns.]

Are you telling me now that there is type checking when using DBserver
Editor generated access/assigns? Again, they are just
fieldputs/fieldgets with Usual datatype, they accept anything and your
application will also bomb out when you use the wrong datatype.
ACCESS DATUM CLASS BoekingSrv

RETURN SELF:FieldGet(#DATUM)

ASSIGN DATUM(uValue) CLASS BoekingSrv

RETURN SELF:FieldPut(#DATUM, uValue)

I fail to see the difference between
Boekingsrv:datum := "blahbla" // wrong datatype, will bomb out in
runtime
or Boekingsrv:fieldput(#datum, "blahbla") // idem

where's the type checking?

[Geoff Schaller]

Paul,

Post by Paul D B
Geoff, what sample code? There wasn't any. (I read your post again, btw)

Perhaps you missed. Here it is again:

cMyVar := oServer:Fieldget(#MyField)

Post by Paul D B
Are you telling me now that there is type checking when using DBserver
Editor generated access/assigns?

Hmmmm... perhaps you missed it again. I said I have built a class
generator in VO to replace the DBserver editor because I wanted strongly
typed access/assigns and this is what I recommend. As second best you
can use the DBServer editor but then you have too much work to do but it
does at least provide a class framework.

Such class generators are very simple to write and I have posted the
code in this forum several times. I can do so again if asked...

Do you understand now?

Geoff

[Paul D B]

Post by Geoff Schaller
Paul,

Post by Paul D B
Geoff, what sample code? There wasn't any. (I read your post again, btw)

cMyVar := oServer:Fieldget(#MyField)

Post by Paul D B
Are you telling me now that there is type checking when using
DBserver Editor generated access/assigns?

Hmmmm... perhaps you missed it again. I said I have built a class
generator in VO to replace the DBserver editor because I wanted
strongly typed access/assigns and this is what I recommend. As second
best you can use the DBServer editor but then you have too much work
to do but it does at least provide a class framework.
Such class generators are very simple to write and I have posted the
code in this forum several times. I can do so again if asked...
Do you understand now?
Geoff

Here is your original post dated 10/10/2007 on which I replied:

<snip>
Sql, SQL and SQL...

Get the picture <g>.

But don't scrap the server classes with their accesses and assigns. We
have a small code generator written in VO to open a DBF and its indexes
and build strongly typed classes to use in your code. DBF or SQL.

Honestly, using Fieldput and get etc just invites code bugs and
maintenance problems for the future. Having that right-click
availability of field names also speeds up code design and makes your
code far more portable to C# or ADO.Net.

Geoff
<snip>


so where is the sample code?
You missed, I guess.
to help you out, you posted that afterwards.

[Geoff Schaller]

Paul,

I don't see anywhere in my post where I referenced 'sample code' at all
so my assumption is that you wanted to see sample code of how the bugs
could arise. I obliged.

Geoff

PS - If anyone is interested in my class code generator, it is trivial
stuff - I've handed it out at most VO conferences - but I can put it up
on our website over the weekend. It is just the VO one on steroids.

Paul,

Post by Paul D B
Geoff, what sample code? There wasn't any. (I read your post again, btw)

[Geoff Schaller]

Ian,

(Can you do us a favour please and top post... saves us lazy writers
scrolling and you can keep the post shorter. We don't need all the
originals.)

Post by Ian
Are you saying that I should continue to use the dbserver editor.

Yes and no. Use the dbserver editor to generate code by all means and
then ignore it. Cut out all the fieldspec code though. I have built a
code generator to do that because I want strongly typed classes,
auto-assigned field specs and other things.

Post by Ian
you also saying that I should keep the access/assign on my widnow
controls and not use fieldget/fieldput.

No - definitely not. They are an abomination and should never have been
invented. It has only lead to poor code and poor performance over the
years. I know why it was done but I think it was wrong.

Post by Ian
I am a bit confused as some of your papers I have downloaded say I
should get rid of access/assign and use fieldget/fieldput. have I
misunderstood you somewhere or am I reading old data.

Just do not link your controls to fields for live update. Go back to
traditional scatter gather and if you strongly typed your server classes
with field names, so much the better. Try to avoid field put and get
entirely. Its bad for business.

Post by Ian
Do I still keep using the dbserver editor yes or no ?

Yes but for server only - delete all the fieldspecs generated. Better
yet. Turn them off. Better still, use a code generator like mine.

Post by Ian
Do I keep the access/assign on my window controls yes or no ?

No.

Post by Ian
Do I forget about using fieldput/fieldget yes or no ?

Yes - use strongly typed classes. Example below.

Geoff



METHOD PreInit() CLASS Books

LOCAL oGlobal AS GCSGlobalObjectBase

oGlobal := GetGlobal()

// this processing is required because "Books" requires a separate
connection
// and in DBF mode, needs to override the default DBF path
SELF:cDBFPath := oGlobal:ROOT_DIRECTORY
SELF:cCatalog := oGlobal:MASTERDATABASE

RETURN NIL
CLASS Books INHERIT MultiServer

DECLARE ACCESS COMPANY
DECLARE ASSIGN COMPANY
DECLARE ACCESS DESCRIPT
DECLARE ASSIGN DESCRIPT
DECLARE ACCESS SHORTNAME
DECLARE ASSIGN SHORTNAME
DECLARE ACCESS APPNAME
DECLARE ASSIGN APPNAME
DECLARE ACCESS REGNUM
DECLARE ASSIGN REGNUM
DECLARE ACCESS REGSTATUS
DECLARE ASSIGN REGSTATUS

METHOD Init(oWin, cInitOrder, lShare, lNew, lAddDefaultRecords) CLASS
Books

SELF:NoHistory := TRUE // GCS 12/08/2007

// Contains a list of all generated dataabses
SELF:HyperLabel := HyperLabel{#Books, "Books", "Books", "Books"}
SUPER:Init(oWin, "BOOKS", cInitOrder, lShare, lNew, lAddDefaultRecords)

RETURN SELF

ACCESS FieldDesc CLASS Books

LOCAL aRet AS ARRAY

aRet := ArrayCreate(6)

// { <DBC_SYMBOL>, <DBC_NAME>, <DBC_FIELDSPEC> }
aRet[ 1] := {#COMPANY, "COMPANY", CHARACTER50{} }
aRet[ 2] := {#DESCRIPT, "DESCRIPT", CHARACTER100{} }
aRet[ 3] := {#SHORTNAME, "SHORTNAME", CHARACTER20{} }
aRet[ 4] := {#APPNAME, "APPNAME", CHARACTER15{} }
aRet[ 5] := {#REGNUM, "REGNUM", CHARACTER50{} }
aRet[ 6] := {#REGSTATUS, "REGSTATUS", CHARACTER12{} }

RETURN aRet

ACCESS IndexList CLASS Books

LOCAL aRet AS ARRAY

// { <DBC_TAGNAME>, <DBC_DUPLICATE>, <DBC_ASCENDING>, <DBC_KEYEXP>,
<DBC_FOREXP>, <DBC_FIELDS>, <DBC_SQLFOREXP> }

aRet := ArrayCreate(1)

aRet[1] := {"SHORTNAM", TRUE, FALSE, [SHORTNAME], [], {[SHORTNAME]},
[]}

RETURN aRet

ACCESS COMPANY AS STRING PASCAL CLASS Books
LOCAL cCOMPANY AS STRING
cCOMPANY := SELF:FIELDGET(#COMPANY)
RETURN cCOMPANY

ASSIGN COMPANY (cCOMPANY AS STRING) AS STRING PASCAL CLASS Books
SELF:FIELDPUT(#COMPANY, cCOMPANY)
RETURN cCOMPANY

ACCESS DESCRIPT AS STRING PASCAL CLASS Books
LOCAL cDESCRIPT AS STRING
cDESCRIPT := SELF:FIELDGET(#DESCRIPT)
RETURN cDESCRIPT

ASSIGN DESCRIPT (cDESCRIPT AS STRING) AS STRING PASCAL CLASS Books
SELF:FIELDPUT(#DESCRIPT, cDESCRIPT)
RETURN cDESCRIPT

ACCESS SHORTNAME AS STRING PASCAL CLASS Books
LOCAL cSHORTNAME AS STRING
cSHORTNAME := SELF:FIELDGET(#SHORTNAME)
RETURN cSHORTNAME

ASSIGN SHORTNAME (cSHORTNAME AS STRING) AS STRING PASCAL CLASS Books
SELF:FIELDPUT(#SHORTNAME, cSHORTNAME)
RETURN cSHORTNAME

ACCESS APPNAME AS STRING PASCAL CLASS Books
LOCAL cAPPNAME AS STRING
cAPPNAME := SELF:FIELDGET(#APPNAME)
RETURN cAPPNAME

ASSIGN APPNAME (cAPPNAME AS STRING) AS STRING PASCAL CLASS Books
SELF:FIELDPUT(#APPNAME, cAPPNAME)
RETURN cAPPNAME

ACCESS REGNUM AS STRING PASCAL CLASS Books
LOCAL cREGNUM AS STRING
cREGNUM := SELF:FIELDGET(#REGNUM)
RETURN cREGNUM

ASSIGN REGNUM (cREGNUM AS STRING) AS STRING PASCAL CLASS Books
SELF:FIELDPUT(#REGNUM, cREGNUM)
RETURN cREGNUM

ACCESS REGSTATUS AS STRING PASCAL CLASS Books
LOCAL cREGSTATUS AS STRING
cREGSTATUS := SELF:FIELDGET(#REGSTATUS)
RETURN cREGSTATUS

ASSIGN REGSTATUS (cREGSTATUS AS STRING) AS STRING PASCAL CLASS Books
SELF:FIELDPUT(#REGSTATUS, cREGSTATUS)
RETURN cREGSTATUS

DEFINE Books_OrderBy_SHORTNAM := "SHORTNAM" // SHORTNAME

[Ian]

Post by Ian
Hi all,
I am re-writing my apps to bring them more up to date. I have decided
to re-write the whole lot as there is a lot of old and bad code in the
current version that I want to get rid of. I am writing the new one as
a dbf/cdx system with a view that I will produce an sql version at a
later date.
I am doing the dbf/cdx first as I am familiar with that code and most
of my customers wont move to sql but I still need amore up to date and
more compact version of the current system hence the rewrite.
To try and make the move to sql easier I have created my window so it
does not create the access/assign methods. I am then accessing the
sle's on the window using fieldget and fieldput. My question is this,
am I right to stop the window generating acess and assigns and am I
write to use fieldget and fieldput from the start if I want to move
the code to sql at a later date.
Second question is I have seen a lot about not using the dbserver
editor as it should be avoided if moving to sql at a later stage. How
do you actually get your servers without using the dbserver editor.
I know I am doing twice the work dbf and sql but I have to do a dbf
version update for some customers (hence the complete re-write) but I
want to make sure the re-write I am doing is done in a way that makes
the later move to sql as easy as it can be.
Any help would be appreciated.
Regards,
Ian

Hi Paul,

Yes using a small library of field specs makes sense and it means I
can dump the dbserver editor stuff as this is a big overhead in an app
with 72 tables. I think I will take that route. It also seems I need
to dump the access/assigns from the windows and start using fieldput/
fieldget as per your earlier post.

I thought this may be the right way to go but I got confused when
Geoff said:-

<Honestly, using Fieldput and get etc just invites code bugs and
maintenance problems for the future. Having that right-click
availability of field names also speeds up code design and makes
your
code far more portable to C# or ADO.Net.>


I have looked at Geoffs example code, but my skills are not far enough
advanced to understand what he is saying so I will need to study that
in more detail.

<GEOFF>, I have downloaded your papers on migrating from dbf to sql> I
will read those and see if I can get into it at my level.

Thanks for the advice .

Ian

[Paul D B]

Post by Ian
Hi Paul,
Yes using a small library of field specs makes sense and it means I
can dump the dbserver editor stuff as this is a big overhead in an app
with 72 tables.

Of course, e.g. you need only one fieldspec for a date field, nomatter
how many datefields you've got in all of your 72 tables.

I think I will take that route. It also seems I need

Post by Ian
to dump the access/assigns from the windows and start using fieldput/
fieldget as per your earlier post.

It's your choice. IMO, you should get rid of the standard access/assigns
that are created by the DBserver editor because they don't add a lot
extra functionality - despite what Geof says (but he is confusing with
his own strong typed access/assigns)

Post by Ian
I thought this may be the right way to go but I got confused when
Geoff said:-

that's normal <g>

Post by Ian
<Honestly, using Fieldput and get etc just invites code bugs and
maintenance problems for the future. Having that right-click
availability of field names also speeds up code design and makes
your
code far more portable to C# or ADO.Net.>
I have looked at Geoffs example code, but my skills are not far enough
advanced to understand what he is saying so I will need to study that
in more detail.

don't worry, you need a special mind to understand Geoff's code. He is
not always an adept of the KISS principle.

[Ian]

Post by Ian
Hi all,
I am re-writing my apps to bring them more up to date. I have decided
to re-write the whole lot as there is a lot of old and bad code in the
current version that I want to get rid of. I am writing the new one as
a dbf/cdx system with a view that I will produce an sql version at a
later date.
I am doing the dbf/cdx first as I am familiar with that code and most
of my customers wont move to sql but I still need amore up to date and
more compact version of the current system hence the rewrite.
To try and make the move to sql easier I have created my window so it
does not create the access/assign methods. I am then accessing the
sle's on the window using fieldget and fieldput. My question is this,
am I right to stop the window generating acess and assigns and am I
write to use fieldget and fieldput from the start if I want to move
the code to sql at a later date.
Second question is I have seen a lot about not using the dbserver
editor as it should be avoided if moving to sql at a later stage. How
do you actually get your servers without using the dbserver editor.
I know I am doing twice the work dbf and sql but I have to do a dbf
version update for some customers (hence the complete re-write) but I
want to make sure the re-write I am doing is done in a way that makes
the later move to sql as easy as it can be.
Any help would be appreciated.
Regards,
Ian

Hi Paul,

Thanks again for your reply. What you are saying seems to make a lot
of sense. I think I will dump all of the access/assign's on the
servers as you suggest as these offer very little. I think I will also
dump the access/assign on the windows and use fieldget/fieldput
directly. I know what Geoff said about problems this may cause at
runtime, but with some thought I think these potential problems can be
covered.

I am trying to create one said of windows. Then have a library of
methods for the dbf version and another library of methods for the sql
version as I need to run both due to customer requirements.

If I can code the dbf methods right I may get away with just one lot
of code that will cover both options. I live in hope.

Thanks for the clear help.

Ian

[Ian]

Post by Ian
Hi all,
I am re-writing my apps to bring them more up to date. I have decided
to re-write the whole lot as there is a lot of old and bad code in the
current version that I want to get rid of. I am writing the new one as
a dbf/cdx system with a view that I will produce an sql version at a
later date.
I am doing the dbf/cdx first as I am familiar with that code and most
of my customers wont move to sql but I still need amore up to date and
more compact version of the current system hence the rewrite.
To try and make the move to sql easier I have created my window so it
does not create the access/assign methods. I am then accessing the
sle's on the window using fieldget and fieldput. My question is this,
am I right to stop the window generating acess and assigns and am I
write to use fieldget and fieldput from the start if I want to move
the code to sql at a later date.
Second question is I have seen a lot about not using the dbserver
editor as it should be avoided if moving to sql at a later stage. How
do you actually get your servers without using the dbserver editor.
I know I am doing twice the work dbf and sql but I have to do a dbf
version update for some customers (hence the complete re-write) but I
want to make sure the re-write I am doing is done in a way that makes
the later move to sql as easy as it can be.
Any help would be appreciated.
Regards,
Ian

Hi All,

Thanks for all of the advice (especially Paul) all of which has
helped. I have taken on board all of the advice suggested and decided
to use the following approach.

Continue to use the DBserver editor but not use its access/assigns

Continue to use the access/assigns in the window editor as it aids
coding

Making all calls to the dbf's using fieldget/fieldput

The dbservers will only be linked in on the dbf version so they should
be ok as they are. The fieldput/fieldget logic should help with the
sql version.

Thanks for all the help.

Ian