Table Restructure - Part 2

Steve688 · Jul 6, 2005

I am trying to change the structure of a table with Objectpal. Tony helped me greatly in this post:

http://www.tek-tips.com/viewthread.cfm?qid=1002986&page=9

but I can't figure out why the

RIV:Field_struc is the perfect structure but it is not using that example to restructure the actual table. Code follows:

Code:

status = "  Restructuring source file"
		Tbl.attach(sourcefile)
		Tbl.enumFieldStruct( ":PRIV:field_struct.db" )
		tcFlds.open(":PRIV:field_struct.db" )
		tcFlds.edit()
		scan tcFlds :
			if tcFlds."Field Name" = "EXPIRYDATE" then
				tcFlds."Type" = "DATE"			
			quitLoop
			endif
		endscan
		scan tcFlds :
			if tcFlds."Field Name" = "CANCELDATE" then
				tcFlds."Type" = "DATE"			
			quitLoop
			endif
		endscan
		scan tcFlds :
			if tcFlds."Field Name" = "JOINDATE" then
				tcFlds."Type" = "DATE"			
			quitLoop
			endif
		endscan
		scan tcFlds :
			if tcFlds."Field Name" = "DDSBEGIN" then
				tcFlds."Type" = "DATE"			
			quitLoop
			endif
		endscan
		scan tcFlds :
			if tcFlds."Field Name" = "DDSEND" then
				tcFlds."Type" = "DATE"			
			quitLoop
			endif
		endscan
		scan tcFlds :
			if tcFlds."Field Name" = "LASTUPDATEDDATE" then
				tcFlds."Type" = "DATE"			
			quitLoop
			endif
		endscan
		scan tcFlds :
			if tcFlds."Field Name" = "ADDRESS3" then
				tcFlds."Type" = "ALPHA"	
				tcFlds."Size" = 30		
			quitLoop
			endif
		endscan
		scan tcFlds :
			if tcFlds."Field Name" = "DDSRATE" then
				tcFlds."Type" = "$"					
			quitLoop
			endif
		endscan
		scan tcFlds :
			if tcFlds."Field Name" = "MISC" then
				tcFlds."Type" = "ALPHA"	
				tcFlds."Size" = 30		
			quitLoop
			endif
		endscan
		tcFlds.endEdit()
		tcFlds.close()	
		dynNewStru["FIELDSTRUCT"] = ":PRIV:field_struct.db"
		Tbl.restructure(dynNewStru)

TonyMcGuire · Jul 6, 2005

I'd try adding the Warnings element to the dynarray, and an 'if not' to the actual restructure:

Code:

        Tbl.attach(sourcefile)
        Tbl.enumFieldStruct( ":PRIV:field_struct.db" )
        Tbl.unattach()
        tcFlds.open(":PRIV:field_struct.db" )
        tcFlds.edit()
scan tcFlds :

switch
  case tcFlds."Field Name" = "EXPIRYDATE" : 
    tcFlds."Type" = "DATE"
  case tcFlds."Field Name" = "CANCELDATE" : 
    tcFlds."Type" = "DATE"
  case tcFlds."Field Name" = "JOINDATE"   : 
    tcFlds."Type" = "DATE"
  case tcFlds."Field Name" = "DDSBEGIN"   : 
    tcFlds."Type" = "DATE"
  case tcFlds."Field Name" = "DDSEND"     : 
    tcFlds."Type" = "DATE"
  case tcFlds."Field Name" = "LASTUPDATEDDATE" :
    tcFlds."Type" = "DATE"
  case tcFlds."Field Name" = "ADDRESS3"   :
    tcFlds."Type" = "ALPHA"    
    tcFlds."Size" = 30        
  case tcFlds."Field Name" = "DDSRATE"    :
    tcFlds."Type" = "$"
  case tcFlds."Field Name" = "MISC"       : 
    tcFlds."Type" = "ALPHA"
    tcFlds."Size" = 30        
endswitch

endscan
        tcFlds.endEdit()
        tcFlds.close()    

        Tbl.attach(sourcefile)
        dynNewStru["FIELDSTRUCT"] = ":PRIV:field_struct.db"
[b]
        dynNewStru["Warnings"]=True
[/b]
[b]        
        if not Tbl.restructure(dynNewStru) then
          errorshow()
        endif
[/b]
        Tbl.unattach()

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

Steve688 · Jul 6, 2005

Hi Tony,

Thanks for the troubleshooting tips. It did now display an error and I can plainly see that it is reverting to using :WORK: in the file path, even though I don't ever specify it. I changed the working directory and that should be an easy fix.

-Steve

TonyMcGuire · Jul 6, 2005

If you don't specify a path, :work: will always be used by Paradox.

But, WHERE is it using :WORK:?

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

Steve688 · Jul 7, 2005

IT's creeping in somewhere, maybe here at the beginning:

Code:

Tbl.attach(sourcefile)

or at the end:

Code:

Tbl.attach(sourcefile)
        dynNewStru["FIELDSTRUCT"] = ":PRIV:field_struct.db"

Although the variable sourcefile example is exactly:

:SOURCE

DSUpdate_QC61_Dec122003_Jul052005.DB

Possible problems with the long filename? (Paradox 8)

TonyMcGuire · Jul 7, 2005

When you said "and I can plainly see that it is reverting to using :WORK: in the file path", how could you 'plainly see'?

Is the error it is throwing up a hint? If so, what is the content of the error?

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

TonyMcGuire · Jul 7, 2005

Maybe the better question is, Where is :SOURCE: pointing to?

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

Steve688 · Jul 7, 2005

I could plainly see because of the error thrown when the WORK directory is pointing to a sub-directory within my

RIV:.

"Table does not exist
File: C:\Corel\Paradox\Priv\Recruitment\...DDSUpdate_ON54_Dec122003_Jul052005.DB

The table name is correct but the path is my working DIR.
The (sourcefile) variable is:
:SOURCE

DSUpdate_ON54_Dec122003_Jul052005.DB the actual path being: U:\Paradox\xxxxx.db

When I point the :WORK: alias to the actual :SOURCE: path, which is on another server on a mapped drive, it will restructure the table.

I hope I explained that well enough. And thanks for your time so far.

-Steve

TonyMcGuire · Jul 7, 2005

Does that table have lookups or referential integrity defined?

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

Steve688 · Jul 7, 2005

No, neither.

TonyMcGuire · Jul 7, 2005

Hmmm.

You may be running into limitations on length of the path for

RIV:, or even :WORK:

What version of Paradox are you using?

What is the table level of the table you are attempting to restructure?

Just for grins, can you set your

RIV: to c:\pdox\priv (after creating it of course) and try again under circumstances that would otherwise fail?

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

Steve688 · Jul 7, 2005

Paradox 8. Alias Manager will not allow me to change the PRIV directory.

I'm not sure what you mean by the table level.

TonyMcGuire · Jul 7, 2005

Tools | Settings | Preferences | Database

Restructure the table interactively, and at the top of the dialog (title bar) it should tell you the table level.

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

Steve688 · Jul 7, 2005

The title bar is reading:

Restructure Paradox 5.0 for windows table.

Funny you should mention table level. I am just now getting an error that reads "Table level has changed".

TonyMcGuire · Jul 7, 2005

When restructuring? With the error setting to True?

Yep, that causes issues. You won't be able to restructure in OPAL with a table level change as part of it.

Interactively you would have to say 'Yes' to restructure and up the table level.

I don't believe there is a way to do that automagically with the OPAL restructure. (Someone prove me wrong, please.)

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Table Restructure - Part 2

Steve688

IS-IT--Management

TonyMcGuire

Programmer

Steve688

IS-IT--Management

TonyMcGuire

Programmer

Steve688

IS-IT--Management

TonyMcGuire

Programmer

TonyMcGuire

Programmer

Steve688

IS-IT--Management

TonyMcGuire

Programmer

Steve688

IS-IT--Management

TonyMcGuire

Programmer

Steve688

IS-IT--Management

TonyMcGuire

Programmer

Steve688

IS-IT--Management

TonyMcGuire

Programmer

Similar threads

Part and Inventory Search

Sponsor