FYI:

The documentation does not show a INLINE ACCESS ASSIGN METHOD, but it does 
appear to compile.

Any thoughts?

Rodd

I don't see a problem. INLINE ACCESS ASSIGN can all modify the METHOD.

Jim

Rodd Graham wrote:
> FYI:
> 
> The documentation does not show a INLINE ACCESS ASSIGN METHOD, but it does 
> appear to compile.
> 
> Any thoughts?
> 
> Rodd 
> 
>

I should avoid such programming practice.
It is legal, but I don't think it is right.
Because it breaks the golden rule:
- definitions in CLASS...ENDCLASS,
- Procedures in METHODs.

Well, it is just another programming practice.

Best regards,

Jos Luis Otermin
oterminATciudad.com.ar
Enjoy the growing Xbase++ repository
http://ar.groups.yahoo.com/group/XFreeProject/join

Jose Luis Otermin wrote:

> I should avoid such programming practice.
> It is legal, but I don't think it is right.
> Because it breaks the golden rule:
> - definitions in CLASS...ENDCLASS,
> - Procedures in METHODs.

And the documentation is still missing any useful information what INLINE
is good for and if it has any advantage over a conventional method
declaration other than making the code more difficult to maintain 

Thomas

Thomas,

>And the documentation is still missing any useful information what INLINE
>is good for and if it has any advantage over a conventional method
>declaration other than making the code more difficult to maintain 
I have to disagree with you here! there are cases that are MUCH better
to read and maintain using inline methods. I shall write a small
example bellow that is much more readable using inline method's 

sample. (not compiled, not run, just a sample.)

class date
   exported:
       var date
       inline method init(dDate)
          iif(dDate)#nil
             ::date := dDate
          else
             ::date := date()
           endif
           return self    

     inline access method day    ; return val(right(dtos(::date),2))
     inline access method year   ; return val(left(dtos(::date),4))

endclass

As I said, this is just an example, but in my eyes, it is more
readable an maintainable then a totally "spliced" one!
inline methods are very handy when one has to write a number off small
methods. plus there is only one 'point off failure' in your code in
stead off two. 

Regards
Sander Elias
Regards
Sander Elias

Elias,

> >And the documentation is still missing any useful information what INLINE
> >is good for and if it has any advantage over a conventional method
> >declaration other than making the code more difficult to maintain 

I find this words as good as mine.

> I have to disagree with you here! there are cases that are MUCH better
> to read and maintain using inline methods. I shall write a small
> example bellow that is much more readable using inline method's

Now is my turn to disagree with you 
Let me explain my point of view.
Inline methods give you the capability to write code everywhere.
They are like the GoTo clause in GW-Basic. Make your code look like
"spaghetti code", because one have to follow the execution thread in order
to understand what the h*ck it does.
It adds confusion to the declaration including improper statements where
anyone expect to find just simply a list of contents.
If you are the one and only programmer in your team, and want not to share
any knowledge with others, or won't need any help with your programming
problems, then go ahead and do it to feel comfortable.
But I have experienced the need to exchange tips, knowledge, classes,
solutions, etc, and then appeared the CPP (Common Programming Practice).
It is almost world widely accepted and now we can pick a piece of source
code and read it with little or no effort at all.
Please keep in mind I'm not preaching you nor anyone else.
I'm just sharing and explaining my point of view wich is as good as yours.

Best regards,

Jos Luis Otermin
oterminATciudad.com.ar
Enjoy the growing Xbase++ repository
http://ar.groups.yahoo.com/group/XFreeProject/join

Jose Luis Otermin wrote:

>> I have to disagree with you here! there are cases that are MUCH better
>> to read and maintain using inline methods. I shall write a small
>> example bellow that is much more readable using inline method's
> 
[...]
> But I have experienced the need to exchange tips, knowledge, classes,
> solutions, etc, and then appeared the CPP (Common Programming Practice).
> It is almost world widely accepted and now we can pick a piece of source
> code and read it with little or no effort at all.

Even for C, where INLINE can be used to optimize code for speed, it is not
the recommended way of programming (as far as I could read from comments
spread all over the web)

Thomas

Another downside of INLINE is that an error in the method will only 
report the method line number not the actual line were the error 
occured. ie there is an error somewhere in this method.


Jim

Thomas Braun wrote:

> Jose Luis Otermin wrote:
> 
> 
>>>I have to disagree with you here! there are cases that are MUCH better
>>>to read and maintain using inline methods. I shall write a small
>>>example bellow that is much more readable using inline method's
>>
> [...]
> 
>>But I have experienced the need to exchange tips, knowledge, classes,
>>solutions, etc, and then appeared the CPP (Common Programming Practice).
>>It is almost world widely accepted and now we can pick a piece of source
>>code and read it with little or no effort at all.
> 
> 
> Even for C, where INLINE can be used to optimize code for speed, it is not
> the recommended way of programming (as far as I could read from comments
> spread all over the web)
> 
> Thomas

Jose,

Speaking of GWBasic, have you ever run it on a 2Ghz+ processor?  It is very 
quick.

Rodd

Rodd,

> Speaking of GWBasic, have you ever run it on a 2Ghz+ processor?  It is
very  quick.

Certainly... I almost have forgotten GW.
But it must be many many faster than other new languages.

Best regards,

Jos Luis Otermin
oterminATciudad.com.ar
Enjoy the growing Xbase++ repository
http://ar.groups.yahoo.com/group/XFreeProject/join

Hi,

> what INLINE
> is good for and if it has any advantage over a conventional method

Here a sample where INLINE can help you to write less code

#xcommand PROPERTY <prop> => ;
          INLINE ACCESS ASSIGN METHOD <prop>(value) ;
          ; if pCount() > 0 ; 
_MyCAssignFunction(::HandleOfWhatever,<"prop">,value) ; end ;
          ; return _MyCAccessFunction(::HandleOfWhatever,<"prop">)

CLASS MyWrapperClass
DATA HandleOfWhatever
EXPORTED:
METHOD init()
METHOD Attach(nHandle)
METHOD Detach(nHandle)

PROPERTY Prop1
PROPERTY Prop2
PROPERTY Prop3
PROPERTY Prop4
 ....... more properties .....
ENDCLASS


Regards,
Pablo Botella

Pablo,

> Here a sample where INLINE can help you to write less code
> 
> #xcommand PROPERTY <prop> => ;
>           INLINE ACCESS ASSIGN METHOD <prop>(value) ;
>           ; if pCount() > 0 ; 
> _MyCAssignFunction(::HandleOfWhatever,<"prop">,value) ; end ;
>           ; return _MyCAccessFunction(::HandleOfWhatever,<"prop">)

Correct me if I'm wrong, but won't this create the class at runtime rather
than compile time?

Also, you can hook a context-ware pre-processor into PBUILD which can do
stuff a different way.  I've not tried it, but I guess you could do
something like this using the NASM pr-processor:


CLASS MyWrapperClass
EXPORTED:
   METHOD init()
     here is some init code
     methreturn x

   METHOD Attach(nHandle)
     here is some init code
     methreturn x

   METHOD Detach(nHandle)
     here is some init code
     methreturn x

   PROPERTY Prop1
   PROPERTY Prop2
   PROPERTY Prop3
   PROPERTY Prop4

ENDCLASS

...and get the pr-processor to convert that to:

CLASS MyWrapperClass
EXPORTED:
   METHOD init
   METHOD Attach
   METHOD Detach
   ACCESS ASSIGN METHOD prop1
   ACCESS ASSIGN METHOD prop2
   ACCESS ASSIGN METHOD prop3
   ACCESS ASSIGN METHOD prop4
ENDCLASS

METHOD MyWrapperClass:init()
     here is some init code
     methreturn x

etc. However, I don't really see the point. Writing to seperated methods is
easier to debug.

Regards,

Phil Ide

*******************************************
*   Xbase++ FAQ, Libraries and Sources:   *
*   goto: http://www.idep.org.uk/xbase    *
* --------------------------------------- *
* www.xodc.org.uk - openSource Dev-Center *
*******************************************

aaawoOOoggggaaaa! ...aaawoOOoggggaaaa! ....DIVE! DIVE!!!

Phil,

> etc. However, I don't really see the point. Writing to seperated methods
is
> easier to debug.

It seems you have forgotten the dBASE times where programmers used to write
PROC, RETU, FUNC, etc.

That wasn't illegal or wrong, but it became a nightmare (at least to me) to
maintain and debug such kind of programs.
Same happened with the naming of variables.
Most of the times some programmers used to name variables with the same name
as fields of the current DBF and that became a headache because the contents
of the supossedly acquired value stored into a variable was really
variable with each DBSkip().
Such strange behaviour of that programs made me think about a failsafe (not
really a true failsafe but a better one) way of programming.
It is good to me. And think ... why not to share such nasty experience and
give an <<advice to the young at heart>>? .

Best regards,

Jos Luis Otermin
oterminATciudad.com.ar
Enjoy the growing Xbase++ repository
http://ar.groups.yahoo.com/group/XFreeProject/join

Jose,

> It seems you have forgotten the dBASE times where programmers used to write
> PROC, RETU, FUNC, etc.

No, which is why I use #xcomand/#xtranslate rather than #command. It
removes ambiguity.  Besides, the NASM preprocessor can be set to case
sensitive (or insensitive).

The interesting thing about this pre-processor is that you can create
contexts, pre-processor variables, pre-processor loops, context local
labels and context-local macros.  Here's an example fro the NASM docs to
create IF..ELSE..END constructs.  Note that there is NO assembly code in
this.  The point I'd like to make is that if we had this much power in the
Xbase++ pre-processor, it would increase the extendability of the language
enormously.

%macro if 1 

    %push if 
    j%-1  %$ifnot 

%endmacro 

%macro else 0 

  %ifctx if 
        %repl   else 
        jmp     %$ifend 
        %$ifnot: 
  %else 
        %error  "expected `if' before `else'" 
  %endif 

%endmacro 

%macro endif 0 

  %ifctx if 
        %$ifnot: 
        %pop 
  %elifctx      else 
        %$ifend: 
        %pop 
  %else 
        %error  "expected `if' or `else' before `endif'" 
  %endif 

%endmacro


Regards,

Phil Ide

*******************************************
*   Xbase++ FAQ, Libraries and Sources:   *
*   goto: http://www.idep.org.uk/xbase    *
* --------------------------------------- *
* www.xodc.org.uk - openSource Dev-Center *
*******************************************

Patience -- Wait control

Phil,

> Correct me if I'm wrong, but won't this create the class at runtime rather
> than compile time?
Try to compile a class with INLINE methods and also with separate 
implementation
and disasemble the results.In both cases the compiler will produce a 
separate near proc and sets the context call exactly in the same manner
so performance will be exactly the same.

I also prefer a separate declaration / implementation when possible, this 
allow to use the declaration as a reference.
As I was said to Rodd my only purpose was illustrate one posible ussage of 
the inline clause.

Regards,
Pablo

Jose,

I absolutely agree with the 'golden rule' of separating declaration from 
implementation.  However, in this case I am trying to match Classy 
delegation class syntax with:

#xcommand VAR <VarName> IS <MessageName> TO <CVarName> => ;
  INLINE ACCESS ASSIGN METHOD <VarName>(Value)            ;;
    if pcount()>0                                         ;;
      ::<CVarName>:<MessageName> := Value                 ;;
    endif                                                 ;;
  RETURN ::<CVarName>:<MessageName>

I started out with only INLINE METHOD, but had a problem since Xbase++ 
distinguishes the messages used for methods from those used for members.  I 
decided to try adding ACCESS ASSIGN even though the documentation does not 
explicitly show the modifiers in the same context.

The above #xcommand allows the following delegation syntax:

class objA
  var objB
  var varC is varD to objB
end class

Would you agree that inline methods that are generated by include file 
#commands might be an acceptable exception to the 'golden rule'?

Rodd

"Jose Luis Otermin" <oterminATciudad.com.ar> wrote in message 
news:BguklSZvFHA.1256@S15147418...
>I should avoid such programming practice.
> It is legal, but I don't think it is right.
> Because it breaks the golden rule:
> - definitions in CLASS...ENDCLASS,
> - Procedures in METHODs.
>
> Well, it is just another programming practice.
>
> -- 
> Best regards,
>
> Jos Luis Otermin
> oterminATciudad.com.ar
> Enjoy the growing Xbase++ repository
> http://ar.groups.yahoo.com/group/XFreeProject/join
>
>

Rodd,

LOL

We are exposing similar ussage at the same time. ( well you win me for about 
10 mins  )

Regards,
Pablo

Pablo,

Ah, but we are doing different things.  I am looking at your property syntax 
and thinking about object persistence in the database.  I am currently using 
a persistence model where the class dynamically follows the database, but 
have been considering reimplementing to where the database dynamically 
follows the class.  Do you do either?

What benefit do you receive implementing the property list as a collection 
(2 dimensional array?) over using discrete instance variables?  Any 
downsides?

What benefit do you recieve using a C function (as opposed to a Xbase++ 
function) for the assign and access of the property collection?

Rodd

"Pablo Botella" <np@pablob.com> wrote in message 
news:A7YHcygvFHA.8168@S15147418...
> Rodd,
>
> LOL
>
> We are exposing similar ussage at the same time. ( well you win me for 
> about 10 mins  )
>
> Regards,
> Pablo
>

Rodd,

> Ah, but we are doing different things.
I only wanted to ilustrate a situation where the INLINE clause is usefull so 
the purpose was the same

>
> What benefit do you receive implementing the property list as a collection 
> (2 dimensional array?) over using discrete instance variables?  Any 
> downsides?
> What benefit do you recieve using a C function (as opposed to a Xbase++ 
> function) for the assign and access of the property collection?

I take this snipet from a wrapper I have to access some properties that the
library provides in this way .Don't was my intention to propose a general
programing technique, just was fit my needs for an specific situation.

Regards,
Pablo

Rodd,
A question not related with the topic. When you dynamically create your 
class connected with a dbf, what approach are you using when you cannot read 
database structure,.i.e. the file is locked or opened by another app 
exclusively? It is possible to use NoIvarCallBack, but a bug exists up to 
version 1.82.

Thanks,
Vladimir

"Rodd Graham" <rodd@tpmco.com> wrote in message 
news:DD3tWdhvFHA.8168@S15147418...
> Pablo,
>
> Ah, but we are doing different things.  I am looking at your property 
> syntax and thinking about object persistence in the database.  I am 
> currently using a persistence model where the class dynamically follows 
> the database, but have been considering reimplementing to where the 
> database dynamically follows the class.  Do you do either?
>
> What benefit do you receive implementing the property list as a collection 
> (2 dimensional array?) over using discrete instance variables?  Any 
> downsides?
>
> What benefit do you recieve using a C function (as opposed to a Xbase++ 
> function) for the assign and access of the property collection?
>
> Rodd
>
> "Pablo Botella" <np@pablob.com> wrote in message 
> news:A7YHcygvFHA.8168@S15147418...
>> Rodd,
>>
>> LOL
>>
>> We are exposing similar ussage at the same time. ( well you win me for 
>> about 10 mins  )
>>
>> Regards,
>> Pablo
>>
>
>

Vladimir,

Not possible in my strategy.  Application opens every table of database at 
startup in shared mode and does not close until application exit.  Takes 
less than 2 seconds to open every table (~70 DBF/CDX) and I don't have to 
worry about access during the application run.  Hence, I can always get the 
dbstruct() and know that it is stable for the duration of the run.

I build the class from the dbstruct() with actual instance variables for 
each field name.  In this way, I do not have to rely on a NoIVarCallback to 
redirect or do name lookups into an array.  I do run the risk of name 
collision between hardcoded instance variables and field based instance 
variables that my naming conventions prevent.

BTW, I do not think that a file lock (flock()?) would prevent opening a 
shared file, but I always use ADS server so I cannot vouch for the Alaska 
DBEs.

Rodd

"Vladimir Iahnenco" <iahnenco@yahoo.com> wrote in message 
news:62vY7zrvFHA.7860@S15147418...
> Rodd,
> A question not related with the topic. When you dynamically create your 
> class connected with a dbf, what approach are you using when you cannot 
> read database structure,.i.e. the file is locked or opened by another app 
> exclusively? It is possible to use NoIvarCallBack, but a bug exists up to 
> version 1.82.
>
> Thanks,
> Vladimir
>
> "Rodd Graham" <rodd@tpmco.com> wrote in message 
> news:DD3tWdhvFHA.8168@S15147418...
>> Pablo,
>>
>> Ah, but we are doing different things.  I am looking at your property 
>> syntax and thinking about object persistence in the database.  I am 
>> currently using a persistence model where the class dynamically follows 
>> the database, but have been considering reimplementing to where the 
>> database dynamically follows the class.  Do you do either?
>>
>> What benefit do you receive implementing the property list as a 
>> collection (2 dimensional array?) over using discrete instance variables? 
>> Any downsides?
>>
>> What benefit do you recieve using a C function (as opposed to a Xbase++ 
>> function) for the assign and access of the property collection?
>>
>> Rodd
>>
>> "Pablo Botella" <np@pablob.com> wrote in message 
>> news:A7YHcygvFHA.8168@S15147418...
>>> Rodd,
>>>
>>> LOL
>>>
>>> We are exposing similar ussage at the same time. ( well you win me for 
>>> about 10 mins  )
>>>
>>> Regards,
>>> Pablo
>>>
>>
>>
>
>

That's fine if you can vouch for the users  they won't open any databases 
with another applications/tools before you run your application.
I also did some tests creating dbf class dynamically. When I couldn't get 
the structure, I created a class without fields access_assign methods, added 
iVar InitError and set IVar Status to FALSE

aMethod[k+nLen] := {"Init",CLASS_EXPORTED+METHOD_INSTANCE,NIL}
aMethod[k+nLen,CLASS_METHOD_BLOCK] := &("{|o,x| o:Xml:Init(x),o:Status := 
If(IsMemberVar(o,'InitError'),.F.,.T.),o:ErrorText:=''}")

Vladimir



"Rodd Graham" <rodd@tpmco.com> wrote in message 
news:LpI47VsvFHA.7860@S15147418...
> Vladimir,
>
> Not possible in my strategy.  Application opens every table of database at 
> startup in shared mode and does not close until application exit.  Takes 
> less than 2 seconds to open every table (~70 DBF/CDX) and I don't have to 
> worry about access during the application run.  Hence, I can always get 
> the dbstruct() and know that it is stable for the duration of the run.
>
> I build the class from the dbstruct() with actual instance variables for 
> each field name.  In this way, I do not have to rely on a NoIVarCallback 
> to redirect or do name lookups into an array.  I do run the risk of name 
> collision between hardcoded instance variables and field based instance 
> variables that my naming conventions prevent.
>
> BTW, I do not think that a file lock (flock()?) would prevent opening a 
> shared file, but I always use ADS server so I cannot vouch for the Alaska 
> DBEs.
>
> Rodd
>
> "Vladimir Iahnenco" <iahnenco@yahoo.com> wrote in message 
> news:62vY7zrvFHA.7860@S15147418...
>> Rodd,
>> A question not related with the topic. When you dynamically create your 
>> class connected with a dbf, what approach are you using when you cannot 
>> read database structure,.i.e. the file is locked or opened by another app 
>> exclusively? It is possible to use NoIvarCallBack, but a bug exists up to 
>> version 1.82.
>>
>> Thanks,
>> Vladimir
>>
>> "Rodd Graham" <rodd@tpmco.com> wrote in message 
>> news:DD3tWdhvFHA.8168@S15147418...
>>> Pablo,
>>>
>>> Ah, but we are doing different things.  I am looking at your property 
>>> syntax and thinking about object persistence in the database.  I am 
>>> currently using a persistence model where the class dynamically follows 
>>> the database, but have been considering reimplementing to where the 
>>> database dynamically follows the class.  Do you do either?
>>>
>>> What benefit do you receive implementing the property list as a 
>>> collection (2 dimensional array?) over using discrete instance 
>>> variables? Any downsides?
>>>
>>> What benefit do you recieve using a C function (as opposed to a Xbase++ 
>>> function) for the assign and access of the property collection?
>>>
>>> Rodd
>>>
>>> "Pablo Botella" <np@pablob.com> wrote in message 
>>> news:A7YHcygvFHA.8168@S15147418...
>>>> Rodd,
>>>>
>>>> LOL
>>>>
>>>> We are exposing similar ussage at the same time. ( well you win me for 
>>>> about 10 mins  )
>>>>
>>>> Regards,
>>>> Pablo
>>>>
>>>
>>>
>>
>>
>
>

Vladimir,

Curious as to what other apps/tools would users use and why?  I tend to be 
hesistant to allow users into the main database tables without control.  I 
maintain a SQL snapshot of our database updated daily for ad-hoc user 
access.

If you have MsSql and want my Xbase++ utility for DBF to SQL, let me know. 
If you have Win2K3 server, I have a script that utilizes VSS to capture a 
database at a moment in time without requiring users to exit or stop 
updating the database.  This script is kind of hairy.

VSS = Volume Shadow Services

Rodd

"Vladimir Iahnenco" <iahnenco@yahoo.com> wrote in message 
news:8iG8NssvFHA.7860@S15147418...
> That's fine if you can vouch for the users  they won't open any 
> databases with another applications/tools before you run your application.
> I also did some tests creating dbf class dynamically. When I couldn't get 
> the structure, I created a class without fields access_assign methods, 
> added iVar InitError and set IVar Status to FALSE
>
> aMethod[k+nLen] := {"Init",CLASS_EXPORTED+METHOD_INSTANCE,NIL}
> aMethod[k+nLen,CLASS_METHOD_BLOCK] := &("{|o,x| o:Xml:Init(x),o:Status := 
> If(IsMemberVar(o,'InitError'),.F.,.T.),o:ErrorText:=''}")
>
> Vladimir
>
>
>
> "Rodd Graham" <rodd@tpmco.com> wrote in message 
> news:LpI47VsvFHA.7860@S15147418...
>> Vladimir,
>>
>> Not possible in my strategy.  Application opens every table of database 
>> at startup in shared mode and does not close until application exit. 
>> Takes less than 2 seconds to open every table (~70 DBF/CDX) and I don't 
>> have to worry about access during the application run.  Hence, I can 
>> always get the dbstruct() and know that it is stable for the duration of 
>> the run.
>>
>> I build the class from the dbstruct() with actual instance variables for 
>> each field name.  In this way, I do not have to rely on a NoIVarCallback 
>> to redirect or do name lookups into an array.  I do run the risk of name 
>> collision between hardcoded instance variables and field based instance 
>> variables that my naming conventions prevent.
>>
>> BTW, I do not think that a file lock (flock()?) would prevent opening a 
>> shared file, but I always use ADS server so I cannot vouch for the Alaska 
>> DBEs.
>>
>> Rodd
>>
>> "Vladimir Iahnenco" <iahnenco@yahoo.com> wrote in message 
>> news:62vY7zrvFHA.7860@S15147418...
>>> Rodd,
>>> A question not related with the topic. When you dynamically create your 
>>> class connected with a dbf, what approach are you using when you cannot 
>>> read database structure,.i.e. the file is locked or opened by another 
>>> app exclusively? It is possible to use NoIvarCallBack, but a bug exists 
>>> up to version 1.82.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> "Rodd Graham" <rodd@tpmco.com> wrote in message 
>>> news:DD3tWdhvFHA.8168@S15147418...
>>>> Pablo,
>>>>
>>>> Ah, but we are doing different things.  I am looking at your property 
>>>> syntax and thinking about object persistence in the database.  I am 
>>>> currently using a persistence model where the class dynamically follows 
>>>> the database, but have been considering reimplementing to where the 
>>>> database dynamically follows the class.  Do you do either?
>>>>
>>>> What benefit do you receive implementing the property list as a 
>>>> collection (2 dimensional array?) over using discrete instance 
>>>> variables? Any downsides?
>>>>
>>>> What benefit do you recieve using a C function (as opposed to a Xbase++ 
>>>> function) for the assign and access of the property collection?
>>>>
>>>> Rodd
>>>>
>>>> "Pablo Botella" <np@pablob.com> wrote in message 
>>>> news:A7YHcygvFHA.8168@S15147418...
>>>>> Rodd,
>>>>>
>>>>> LOL
>>>>>
>>>>> We are exposing similar ussage at the same time. ( well you win me for 
>>>>> about 10 mins  )
>>>>>
>>>>> Regards,
>>>>> Pablo
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Rodd,

> If you have MsSql and want my Xbase++ utility for DBF to SQL, let me know.

May I ask you how you connected Xb++ with MySQL?

Best regards,

Jos Luis Otermin
oterminATciudad.com.ar
Enjoy the growing Xbase++ repository
http://ar.groups.yahoo.com/group/XFreeProject/join

I didn't.  The utility wrtes two sql scripts (drop and create table (.tab) , 
index table (.ix) ), one bcp format file (.fmt), and one bcp binary file 
(.bcp).  It creates Sql indexes equivalent to the structural CDX keys.  I 
limit my CDX key expressions to simple columns in character form with N type 
using STR(), D type using dtos, and L type using IIF().

I have 6 tables with more than 1M rows the largest of which is 14M.  It was 
too slow to load without the bcp api and since the database is for query 
only, transaction processing is turned off.  Total xBase++ convert and bcp 
load time is approx 3.5 hours for 6.1GB of .DBF.  The entire process is 
single threaded and a majority of the time is spent in the xBase++ Dbf to 
Bcp conversion utility.

Then I load into MsSql with this .cmd script:

@echo off

for %%I in (*.bcp) do (
  isql -S ServerName -d DatabaseName -E -e -p -n -i %%~nI.tab
  bcp DatabaseName.dbo.%%~nI in %%~nI.bcp -f %%~nI.fmt -S 
ServerName -T -q -b 10000
  isql -S ServerName -d DatabaseName -E -e -p -n -i %%~nI.ix
)

Rodd

"Jose Luis Otermin" <oterminATciudad.com.ar> wrote in message 
news:Pi6FzwuvFHA.6160@S15147418...
> Rodd,
>
>> If you have MsSql and want my Xbase++ utility for DBF to SQL, let me 
>> know.
>
> May I ask you how you connected Xb++ with MySQL?
>
>
> -- 
> Best regards,
>
> Jos Luis Otermin
> oterminATciudad.com.ar
> Enjoy the growing Xbase++ repository
> http://ar.groups.yahoo.com/group/XFreeProject/join
>
>

One additional note:

I originally used Microsoft DTS to load, but had failures when DBF:

Date fields exceeded the date range of SQL.  The utility trims out of range 
dates to the min or max date supported by SQL.  This is errant data entry by 
our operators.

Numeric fields overflowed and were replaced by * characters.  The utility 
loads these as SQL nulls.  Again, these are data entry errors.

Date fields that are empty are loaded as SQL nulls.  I think DTS handled 
these ok.

Memo fields were in FPT or DBT format.  While I only use FPT, DTS could not 
dynamically adjust to this difference.

I needed a reliable solution that would run consistently without ongoing 
management or intervention based upon the contents of the DBF.  I wanted a 
simple system that did not rely on row versioning to try to synchronize only 
the changes.  I wanted the schema and indexing of the SQL replica to 
automatically follow the changes in our DBF application.

I also am watching ADS .ADT support in the event that a table exceeds the 
DBF size limits.  I have tried Microsoft DTS against the compatible ADS 
drivers (OLEDB, ODBC) with less than acceptable results.  The DBF to BCP 
utility will also convert .ADT since it is just a different DBE.

Rodd

"Jose Luis Otermin" <oterminATciudad.com.ar> wrote in message 
news:Pi6FzwuvFHA.6160@S15147418...
> Rodd,
>
>> If you have MsSql and want my Xbase++ utility for DBF to SQL, let me 
>> know.
>
> May I ask you how you connected Xb++ with MySQL?
>
>
> -- 
> Best regards,
>
> Jos Luis Otermin
> oterminATciudad.com.ar
> Enjoy the growing Xbase++ repository
> http://ar.groups.yahoo.com/group/XFreeProject/join
>
>

Rodd,

> Would you agree that inline methods that are generated by include file
> #commands might be an acceptable exception to the 'golden rule'?

 of course!

Let me suggest you to do such convertion using the preprocessor but then
take the .ppo output and create a "true" class following the XPP style.
Such way you would have clean code 'golden rule compliant' 

Don't take my words so serious.
I'm a very obsessive programmer and have some rigid rules applied to myself.
Some years ago, one of my colleagues said:
"We could build an entire system starting from Jose's programming scrap."

Best regards,

Jos Luis Otermin
oterminATciudad.com.ar
Enjoy the growing Xbase++ repository
http://ar.groups.yahoo.com/group/XFreeProject/join

...and still there is no "official" answer about the benefits (speed?) of
INLINE... Steffen, are you listening... maybe? 

Thomas

Thomas Braun wrote:
> 
> ...and still there is no "official" answer about the benefits (speed?) of
> INLINE... Steffen, are you listening... maybe? 

INLINE METHODs are simply easier to code from a programmer's point of
view.

You can write the method code within the method declaration and don't
have to maintain a second place in your PRG file apart from the method
declaration.

There is no speed difference between INLINE METHOD and regular METHOD
implamentation.

The only difference is when you analyze an error log:

Line numbers of INLINE METHODs point to the INLINE METHOD declaration,
while line numbers of METHOD point to the actual line of code where the
error occured.

From my experience: I start coding a class using INLINE METHOD
declarations. Once the class is stable, I move the INLINE METHOD code to
a regular METHOD implementation. I have found this to be most productive
in a program/link/debug cycle.

Regards,
--
Hannes

Hannes,

> From my experience: I start coding a class using INLINE METHOD
> declarations. Once the class is stable, I move the INLINE METHOD code to
> a regular METHOD implementation. I have found this to be most productive
> in a program/link/debug cycle.

I wold have thought the other way around would be better, since it is
easier to debug with line numbers - and having got it stable, why not leave
it as out-of-line source?

Regards,

Phil Ide

*******************************************
*   Xbase++ FAQ, Libraries and Sources:   *
*   goto: http://www.idep.org.uk/xbase    *
* --------------------------------------- *
* www.xodc.org.uk - openSource Dev-Center *
*******************************************

Heisenberg may have been here.

Phil,

> > From my experience: I start coding a class using INLINE METHOD
> > declarations. Once the class is stable, I move the INLINE METHOD code to
> > a regular METHOD implementation. I have found this to be most productive
> > in a program/link/debug cycle.
> 
> I wold have thought the other way around would be better, since it is
> easier to debug with line numbers - and having got it stable, why not leave
> it as out-of-line source?

well, experience plays a role here. When I write code in INLINE METHODs,
I know it works. 

I move INLINE METHOD code to METHOD code when I produce a non-debug
version or when the code doesn't work from which I knew in advance it
must work 
 
Regards,
--
Hannes