Forum .LRN Q&A: bug in bulk-mail and notifications with notification > 4k in size

hi!

In the datamodel for 'notifications' in the notifications package 'notif_text' is declared as 'clob'. But the function new that inserts a new notification has the parameter 'notif_text' declared as 'varchar'. Should the parameter type be changed to 'clob'?

I tried to insert a large notification and here is the error that the database returned. The same problem appears in bulk-mail too...

Request Error

ora8.c:3568:ora_tcl_command: error in `OCIStmtExecute ()': ORA-01460:
unimplemented or unreasonable conversion requested

SQL: 
      
    BEGIN
      :1 := bulk_mail.new(creation_user    => :creation_user,
                                      creation_ip      => :creation_ip,
                                      package_id       => :package_id,
                                      send_date        => :send_date,
                                      date_format      => :date_format,
                                      from_addr        => :from_addr,
                                      subject          => :subject,
                                      reply_to         => :reply_to,
                                      extra_headers    => :extra_headers,
                                      message          => :message,
                                      query            => :query,
                                      context_id       => :context_id
      );
    END; 
    
      
    while executing
"ns_ora exec_plsql_bind nsdb0 {
      
    BEGIN
      :1 := bulk_mail.new(creation_user    => :creation_user,
                                      cr..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $ulevel [list ns_ora $type $db $sql] $args"
    invoked from within
"db_exec exec_plsql_bind $db $full_statement_name $sql 2 1 """
    invoked from within
"if { [regexp {:1} $test_sql] } {
	    return [db_exec exec_plsql_bind $db $full_statement_name $sql 2 1 ""]
	} else {
	    return [db_exec dml $db $fu..."
    ("uplevel" body line 5)
    invoked from within
"uplevel 1 $code_block "
    invoked from within
"db_with_handle db {
	# Right now, use :1 as the output value if it occurs in the statement,
	# or not otherwise.
        set test_sql [db_qd_replace_s..."
    (procedure "db_exec_plsql" line 11)
    invoked from within
"db_exec_plsql create_object "
    BEGIN
      :1 :=
${package_name}.new([plsql_utility::generate_attribute_parameter_call
 -prepend ":"  -indent [expr..."
    (procedure "package_instantiate_object" line 106)
    invoked from within
"package_instantiate_object -extra_vars $extra_vars "bulk_mail_message""
    (procedure "bulk_mail::new" line 44)
    invoked from within
"bulk_mail::new  -package_id
[site_node_apm_integration::get_child_package_id -package_key
[bulk_mail::package_key]]  -send_date [template::util::date:..."
    invoked from within
"if {[ns_queryexists "form:confirm"]} {
    form get_values spam_message  community_id from rel_type subject
message send_date referer

    set segment..."
    ("uplevel" body line 61)
    invoked from within
"uplevel {
    	  #
#  Copyright (C) 2001, 2002 MIT
#
#  This file is part of dotLRN.
#
#  dotLRN is free software; you can redistribute it and/or modi..."
    (procedure "code::tcl::/web/ssv2-dev/packages/dotlrn/www/spam" line 2)
    invoked from within
"code::tcl::$__adp_stub"
    invoked from within
"if { [file exists $__adp_stub.tcl] } {

      # ensure that data source preparation procedure exists and is
up-to-date
      adp_init tcl $__adp_stub
..."
    ("uplevel" body line 3)
    invoked from within
"uplevel {

    if { [file exists $__adp_stub.tcl] } {

      # ensure that data source preparation procedure exists and is
up-to-date
      adp_init t..."
    (procedure "adp_prepare" line 3)
    invoked from within
"adp_prepare "
    (procedure "template::adp_parse" line 30)
    invoked from within
"template::adp_parse [file root [ad_conn file]] {}"
    (procedure "adp_parse_ad_conn_file" line 7)
    invoked from within
"$handler"
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
	$handler
      } ad_script_abort val {
	# do nothing
      }"
    invoked from within
"rp_serve_concrete_file [ad_conn file]"
    (procedure "rp_serve_abstract_file" line 60)
    invoked from within
"rp_serve_abstract_file "$root/$path""
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
	rp_serve_abstract_file "$root/$path"
	set tcl_url2file([ad_conn url]) [ad_conn file]
	set tcl_url2path_info([ad_conn url]) [ad_conn path_inf..."

The PL/SQL type is purposely set to varchar instead of clob. This is a trick that
allows us to use clobs (> 4K) but treat them as varchars. We discovered this
through a coding mistake.

Our tests, however, show that we can insert notifications far larger than 4K, so
I'm not sure where your bug is coming from. Can you give us the rundown of
your platform?

The PL/SQL type is purposely set to varchar instead of clob. This is a trick that allows us to use clobs (> 4K) but treat them as varchars. We discovered this through a coding mistake.
FYI, a PL/SQL varchar is not the same as a SQL varchar (or varchar2), since a PL/SQL varchar may contain up to 32KB of text. As a general rule, a PL/SQL variable is limited to 32KB; to manipulate bigger data types, such as clobs, there are locator, essentially pointers to the actual data.