Tricking COTS Into Using Sequences

Question

I am using a COTS software that does about 100-200 concurrent inserts into many tables at a time. This software uses a table to store the values of about 25 sequences. So for each insert, a process has to lock the row, select the value, insert the rows, increment the value and then release the lock. This is not scalable at all and as much as I try I can't get the COTS devlopers to use oracle sequences So I guess one of my questions is that I am looking for the best way to trick the app into using oracle sequences. I am in the process of trying the following, which is creating the oracle sequences, then creating a funtion for each sequence which returns its value. I then create a view that unions all the functions. I then create an instead of update trigger on this view, which does baiscally nothing. This process works pretty well, except for the fact that when the update is done, it queries the view which causes the sequences to increment. So for a single process, the sequence increments during the initial select and then again during the update. So I am not using every other number.
Current Process
create sequence seq_one nocycle noorder cache 10000 start with 1;
create sequence seq_two nocycle noorder cache 10000 start with 1;
create function func_one return number
as
cnt number;
begin
select seq_one.nextval into cnt from dual;
return cnt;
end;
create function func_two return number
as
cnt number;
begin
select seq_two.nextval into cnt from dual;
return cnt;
end;
create view sequences
as
select 'seq_one' Sequence_Name, func_one Sequence_Value from dual
union all
select 'seq_two' Sequence_Name, func_two Sequence_Value from dual;
create trigger trigger_sequences
instead of update on sequences
begin
dbms_output.put_line('');
end;
Thanks for any feedback!!

Answer 1

You are wasting your time doing what is roughly equivalent to trying to prove to someone that the sun comes up in the morning.
Your vendor knows it.
Your vendor doesn't care.
They don't care because companies like yours continue to by their trash so why should they put down their beers and write new
code and go through a testing cycle when it doesn't bring a single dollar to their bottom line? Because some guy is complaining
who's management won't back him up?
The table exists for one of two reasons. Either the vendor wants a single solution for Oracle and SQL Server and other anemic
databases or they are lazy and uneducated. Choose whichever one you wish.
Which takes you back to the choices in my original email. Either your company switches, your find something else to worry about,
or you get out of there and find a better job.