Export SQL question

[Bart Pietercil]

On 13-jun-07, at 15:41, Ruslan Zasukhin wrote:

> On 13/6/07 4:33 PM, "Bart Pietercil" <bart.pietercil at gmail.com> wrote:
>
> Hi Bart,
>
>> Hi List, Ruslan
>>
>> This is the result of an SQL dump for a table:
>>
>> CREATE TABLE "tbl_modules" (
>> "module_name" VARCHAR (2044)  NOT NULL,
>> "module_description" VARCHAR (2044)  NOT NULL,
>> "module_seqnr" VARCHAR (2044)  NOT NULL,
>> "objptr_proj_lang_id" ULONG  NOT NULL INDEXED,
>> "uniq_seqnr" LONG METHOD ('CONCAT(objptr_proj_lang_id,
>> module_seqnr)')  NOT NULL UNIQUE INDEXED,
>> "modification_dt" DATETIME  NOT NULL,
>> "creation_dt" DATETIME  NOT NULL,
>> "objptr_created_by" ULONG  INDEXED,
>> "objptr_modified_by" ULONG  INDEXED);
>>
>> The question goes on the last two lines. As you can see on the name
>> these two fields were created in VStudio as ObjectPointers with
>> Deletion Control SET NULL and target table as "tbl_users"
>> As I was looking for the SQL way of defining an ObjectPointer with
>> deletion control "SET NULL" and did not find any info on the WIKI I
>> exported an existing table.
>>
>> Much to my surprise fields I created as Object Pointers (and show up
>> in VStudio as Object Pointer) are exported as ULong ????
>>
>> Is this an error in the export routine ?
>
> I think if you look down into file, you will find something
>     ALTER TABLE that convert them back to ObjectPtr
>
> This Trick is required to correctly manage RecID values,
> Which in the new db will be different.


No I copied the complete text file, but the dump was created with the  
Dump TABLE command, maybe that makes a difference ?

Still this remains very dangerous in my opinion, at least a warning  
could be written (as comment) in the Dump

.....testing....

I see what you mean, when I do a Dump Database, as you say, an ALTER  
TABLE command is written.

So I would assume that this is also needed when doing a Dump Table ?  
(It is definitely NOT doing this now)


Bart