Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Replication problem.

5 posts in NT Last posting was on 2008-12-15 10:41:19.0Z
mike grace Posted on 2008-12-12 15:05:42.0Z
Date: Fri, 12 Dec 2008 15:05:42 +0000 (UTC)
Message-ID: <b9f6cef845288cb2a823cc8e734@devzone.advantagedatabase.com>
From: mike grace <mikeg@computastat-group.co.uk>
Subject: Replication problem.
Newsgroups: advantage.nt
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-Newsreader: JetBrains Omea Reader 1098.1
X-Antivirus: avast! (VPS 081211-0, 11/12/2008), Outbound message
X-Antivirus-Status: Clean
NNTP-Posting-Host: 217.24.129.66
X-Trace: 12 Dec 2008 07:59:13 -0700, 217.24.129.66
Lines: 33
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!217.24.129.66
Xref: solutions.advantagedatabase.com Advantage.NT:1734
Article PK: 1130780

I am trying to get replication working and keep hitting the following problem.

I have an adt database which I am trying to replicate to free DBF tables.

I have set up the publisher and subscription etc..

Then when I make a change to a table called TCARD, it doesn't replicate and
has the following message in the error table:

Error 7200: AQE Error: State = HY000; NativeError = 5205; [iAnywhere...This
operation is only allowed on Nullable fields within an ADS_VFP table.

The insert that is failing is

EntryID=4, Subscription=Replicate to DBF, Table=TCARD, Record=1851447, SQL=INSERT
INTO "TCARD" ("_ROWID", "JOB_NO", "CODE", "DATE", "NOTE", "USER_ID", "LOCKED_BY")
VALUES ( ?, ?, ?, ?, ?, ?, ? ), Values=( 1851447,04013391 ,25 ,2008-12-12,Enquiry
received on 12/12/08 ,MIKE ,NULL)

Now it is obviously because of the null value but my dbf tables do not support
null just blank as per normal DBF tables. Where is it picking up that this
is a VFP table?

How do I stop this problem from happening?


Also,

Is it possible to replicate to dbf tables without a DD on the destination
side? I want to keep the DBF's free because we have an external report writer
that reads them and won't know anything about the DD.


Edgar Sherman Posted on 2008-12-12 16:13:42.0Z
Date: Fri, 12 Dec 2008 09:13:42 -0700
From: Edgar Sherman <no@email.com>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
Newsgroups: advantage.nt
Subject: Re: Replication problem.
References: <b9f6cef845288cb2a823cc8e734@devzone.advantagedatabase.com>
In-Reply-To: <b9f6cef845288cb2a823cc8e734@devzone.advantagedatabase.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 10.24.34.164
Message-ID: <49428c23@solutions.advantagedatabase.com>
X-Trace: 12 Dec 2008 09:06:59 -0700, 10.24.34.164
Lines: 54
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!10.24.34.164
Xref: solutions.advantagedatabase.com Advantage.NT:1735
Article PK: 1130779

Mike,

This is the problem due to the null fields. The dictionary is not
picking up that it is a VFP table, but is indicating that you must use a
VFP table to be compatible. I am not sure, but I believe if you change
the adt null fields to not null (i.e. insert some "default" value) you
should be good to go as long as the filed types are compatible.

Replication requires a DD. You should not need to worry about attaching
the dbf files to the DD since the header is not changed. The report
writer will be able to use the files as normal. the only "gotcha" is if
you need to alter the table structure you will want to do this through a
dictionary connection so the dictionary meta data will be updated.

Edgar

mike grace wrote:
> I am trying to get replication working and keep hitting the following
> problem.
>
> I have an adt database which I am trying to replicate to free DBF tables.
>
> I have set up the publisher and subscription etc..
>
> Then when I make a change to a table called TCARD, it doesn't replicate
> and has the following message in the error table:
>
> Error 7200: AQE Error: State = HY000; NativeError = 5205;
> [iAnywhere...This operation is only allowed on Nullable fields within an
> ADS_VFP table.
>
> The insert that is failing is
>
> EntryID=4, Subscription=Replicate to DBF, Table=TCARD, Record=1851447,
> SQL=INSERT INTO "TCARD" ("_ROWID", "JOB_NO", "CODE", "DATE", "NOTE",
> "USER_ID", "LOCKED_BY") VALUES ( ?, ?, ?, ?, ?, ?, ? ), Values=(
> 1851447,04013391 ,25 ,2008-12-12,Enquiry received on
> 12/12/08 ,MIKE ,NULL)
>
> Now it is obviously because of the null value but my dbf tables do not
> support null just blank as per normal DBF tables. Where is it picking up
> that this is a VFP table?
>
> How do I stop this problem from happening?
>
>
> Also,
>
> Is it possible to replicate to dbf tables without a DD on the
> destination side? I want to keep the DBF's free because we have an
> external report writer that reads them and won't know anything about the
> DD.
>
>


mike grace Posted on 2008-12-15 10:41:19.0Z
Date: Mon, 15 Dec 2008 10:41:19 +0000 (UTC)
Message-ID: <b9f6cef845638cb2cb8ccd314be@devzone.advantagedatabase.com>
From: mike grace <mikeg@computastat-group.co.uk>
Subject: Re: Replication problem.
Newsgroups: advantage.nt
References: <49428c23@solutions.advantagedatabase.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-Newsreader: JetBrains Omea Reader 1098.1
X-Antivirus: avast! (VPS 081214-0, 14/12/2008), Outbound message
X-Antivirus-Status: Clean
NNTP-Posting-Host: 217.24.129.66
X-Trace: 15 Dec 2008 03:34:49 -0700, 217.24.129.66
Lines: 68
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!217.24.129.66
Xref: solutions.advantagedatabase.com Advantage.NT:1738
Article PK: 1130785

Hi Edgar,

Thanks for the information regarding the DD. Good to know.

Regards

Mike

Hello Edgar,

> Mike,
>
> This is the problem due to the null fields. The dictionary is not
> picking up that it is a VFP table, but is indicating that you must use
> a VFP table to be compatible. I am not sure, but I believe if you
> change the adt null fields to not null (i.e. insert some "default"
> value) you should be good to go as long as the filed types are
> compatible.
>
> Replication requires a DD. You should not need to worry about
> attaching the dbf files to the DD since the header is not changed.
> The report writer will be able to use the files as normal. the only
> "gotcha" is if you need to alter the table structure you will want to
> do this through a dictionary connection so the dictionary meta data
> will be updated.
>
> Edgar
>
> mike grace wrote:
>
>> I am trying to get replication working and keep hitting the following
>> problem.
>>
>> I have an adt database which I am trying to replicate to free DBF
>> tables.
>>
>> I have set up the publisher and subscription etc..
>>
>> Then when I make a change to a table called TCARD, it doesn't
>> replicate and has the following message in the error table:
>>
>> Error 7200: AQE Error: State = HY000; NativeError = 5205;
>> [iAnywhere...This operation is only allowed on Nullable fields within
>> an ADS_VFP table.
>>
>> The insert that is failing is
>>
>> EntryID=4, Subscription=Replicate to DBF, Table=TCARD,
>> Record=1851447, SQL=INSERT INTO "TCARD" ("_ROWID", "JOB_NO", "CODE",
>> "DATE", "NOTE", "USER_ID", "LOCKED_BY") VALUES ( ?, ?, ?, ?, ?, ?, ?
>> ), Values=( 1851447,04013391 ,25 ,2008-12-12,Enquiry received on
>> 12/12/08 ,MIKE ,NULL)
>>
>> Now it is obviously because of the null value but my dbf tables do
>> not support null just blank as per normal DBF tables. Where is it
>> picking up that this is a VFP table?
>>
>> How do I stop this problem from happening?
>>
>> Also,
>>
>> Is it possible to replicate to dbf tables without a DD on the
>> destination side? I want to keep the DBF's free because we have an
>> external report writer that reads them and won't know anything about
>> the DD.
>>


Peter Funk (ADS) Posted on 2008-12-12 16:43:19.0Z
Date: Fri, 12 Dec 2008 16:43:19 +0000 (UTC)
Message-ID: <864d0bcb1657c8cb2a5532fd7772@devzone.advantagedatabase.com>
From: Peter Funk (ADS) <pfunk@nospam.com>
Subject: Re: Replication problem.
Newsgroups: Advantage.NT
References: <b9f6cef845288cb2a823cc8e734@devzone.advantagedatabase.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-Newsreader: JetBrains Omea Pro 1098.1
NNTP-Posting-Host: 10.24.38.185
X-Trace: 12 Dec 2008 09:36:48 -0700, 10.24.38.185
Lines: 31
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!10.24.38.185
Xref: solutions.advantagedatabase.com Advantage.NT:1736
Article PK: 1130782

Hello Mike,
First of all, replicating from an ADT to a DBF is not something we had in
mind when we implemented replication. Because replication uses SQL under
the covers it will work for basic scenarios. Where you might run into problems
is with ADT specific types (modtime, rowversion, etc) and almost certainly
with ON CONFLICT triggers. If the DBF fields are defined properly, then
the ADT data may convert fine. ON CONFLICT triggers will almost certainly
not work since they rely on the CRC values of each record which will likely
be different due to the different table structures. So unless you are using
a very simple & basic replication setup, I would not recommend replicating
from ADT to DBF. Now to answer your question:

The 5205 error indicates that the replication update tried to assign a NULL
value to a non-nullable field. This only applies to Visual Foxpro (VFP)
tables, so when you added the DBF table to the target dictionary, you must
have selected the "Visual Foxpro (DBF/CDX)" table type. If you didn't intend
to use the VFP type, I would re-add the table as a "Foxpro (DBF/CDX)" type.
This is the older, more compatible DBF table type we've had for years and
it will convert NULL values to DBF empty values automatically. The Visual
Foxpro type is new to 9.0 and not the typical DBF type we've always had (it
does add additional functionality, but with a loss of compatability). If
you do wish to use the VFP type, then you can enable NULL value support for
the fields by setting the "Nullable" field property to TRUE. This will allow
replication to assign NULL values to the DBF fields when the ADT fields are
NULL.

Regards,
Peter Funk
Advantage R&D


mike grace Posted on 2008-12-15 10:40:42.0Z
Date: Mon, 15 Dec 2008 10:40:42 +0000 (UTC)
Message-ID: <b9f6cef845628cb2cb8b6b2416e@devzone.advantagedatabase.com>
From: mike grace <mikeg@computastat-group.co.uk>
Subject: Re: Replication problem.
Newsgroups: advantage.nt
References: <864d0bcb1657c8cb2a5532fd7772@devzone.advantagedatabase.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-Newsreader: JetBrains Omea Reader 1098.1
X-Antivirus: avast! (VPS 081214-0, 14/12/2008), Outbound message
X-Antivirus-Status: Clean
NNTP-Posting-Host: 217.24.129.66
X-Trace: 15 Dec 2008 03:34:12 -0700, 217.24.129.66
Lines: 60
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!217.24.129.66
Xref: solutions.advantagedatabase.com Advantage.NT:1737
Article PK: 1130783

Hi Peter,

ADT to DBF replication is only going to be used until we can covert all our
reports to ADT so we will not be using any special ADT field types until
then.

I probably did choose Visual Foxpro by accident.

Regards

Mike

Hello Peter,

> Hello Mike,
> First of all, replicating from an ADT to a DBF is not something we had
> in
> mind when we implemented replication. Because replication uses SQL
> under
> the covers it will work for basic scenarios. Where you might run into
> problems
> is with ADT specific types (modtime, rowversion, etc) and almost
> certainly
> with ON CONFLICT triggers. If the DBF fields are defined properly,
> then
> the ADT data may convert fine. ON CONFLICT triggers will almost
> certainly
> not work since they rely on the CRC values of each record which will
> likely
> be different due to the different table structures. So unless you are
> using
> a very simple & basic replication setup, I would not recommend
> replicating
> from ADT to DBF. Now to answer your question:
> The 5205 error indicates that the replication update tried to assign a
> NULL
> value to a non-nullable field. This only applies to Visual Foxpro
> (VFP)
> tables, so when you added the DBF table to the target dictionary, you
> must
> have selected the "Visual Foxpro (DBF/CDX)" table type. If you didn't
> intend
> to use the VFP type, I would re-add the table as a "Foxpro (DBF/CDX)"
> type.
> This is the older, more compatible DBF table type we've had for years
> and
> it will convert NULL values to DBF empty values automatically. The
> Visual
> Foxpro type is new to 9.0 and not the typical DBF type we've always
> had (it does add additional functionality, but with a loss of
> compatability). If you do wish to use the VFP type, then you can
> enable NULL value support for the fields by setting the "Nullable"
> field property to TRUE. This will allow replication to assign NULL
> values to the DBF fields when the ADT fields are NULL.
>
> Regards,
> Peter Funk
> Advantage R&D