APEX

(job_bag_id_seq.nextval@dblink2

Howard

Just to ask one thing

When we update a value to column it treats as a column value rather than any operation mentioned it..it checks the value against the datatype and updates it

Am i right here?

I'm afraid I don't know what you're asking, really. All I can say by way of reply is that the fact I get a "global names" error indicates that it's seeing the database link, treating it as a database link and producing vaguely appropriate errors accordingly. It's not throwing a data type exception, for example, as it would if I was trying to store some text in a numeric column.

Again, I can only really repeat that example 2 has the same basic code inserting the same basic data as example 1 tries to do. One works, the other doesn't... I don't think that makes it a datatype issue (but I could well be completely wrong on that, of course).

I did wonder whether the first example might work better if it was of the form

...values ((select sequence@dblink2 from dual),'other data','here')...

In other words, whether it's just a syntactical issue. But I didn't test that. I'll give it a whirl...

Just so we are on the same hymn-sheet... This code:

insert into job_bag@dblink1 (job_bag_id, user_id, name, created_date, status)
values
((select job_bag_id_seq.nextval@dblink2 from dual), 80487, 'Some Text', sysdate, 1)

...produces an ORA-02287 Sequence not allowed here error. So again, referring back to the earlier reply, I don't think it's a syntactical issue or a datatype issue.

Oh thanks

Maran Viswarayar

Howard, did you see Metalink note 1047673.6?

I have now, thanks to you!

That seems to get it in one, doesn't it:

The reference to the local sequence has to be qualified so that the remote end knows to call back to the local instance. The qualification is made by appending @local_dbname.domain to the sequence reference if global_names=true.

This also neatly explains why, when I quickly created new db links, set global_names to true and then tried running my example 1 code, the execution failed with an error along the lines of 'don't know that db link name'. Our databases don't know how to talk to each other. A special intermediary database (in which these bits of code were running) knows how to talk to all of them -but the call back meant that db1 was trying to contact db2 directly, and that's not possible for us.

So two mysteries solved in one 7-word post!! Thanks Yas, very much.

You are welcome Howard, this db link behavior was one of the things some developers kept asking me repeatedly about.