One thing that leaps out at me is that you're using both bind_param() and passing a value to execute(). Unless you absolutely have to, don't use bind_param.

Also, you aren't using strict, which means you're not seeing the fact that you never declare or assign to $niin ... that, I suspect, is your problem.

Suggested solution: Comment out the call to bind_param().

I would advise to 'use strict;' but also to 'RaiseError => 1'. This will show you the $DBI::errstr (the error encountered).

You'd normally enclose the DBI-calling code in a eval block:

eval { yourDBIsubroutine() };
if ($@) { print "error:\n$@\n" }
[download]

From the DBI docs:

If you turn "RaiseError" on then you'd normally turn "PrintError" off. If "PrintError" is also on, then the "PrintError" is done first naturally).

(Try 'perldoc DBI' on the commandline)

• As was already said: use strict
• You first create a table (which will be empty) and then you delete its contents, which are not (yet) there or is it possible that meanwhile someone else could have filled the table ((s)he won't be happy to see the data disappear!)?
• You disconnect from the DB after creating the table and immediately reconnect, which seems a bit wasteful on resources (but it could have something to do with user-privileges; I don't know much about Sybase in that respect)
• It is considered advisable to use a fresh lexical variable as filehandle in open. As per perlopentut

  open's first argument can be a reference to a filehandle. As of perl 5.6.0, if the argument is uninitialized, Perl will automatically create a filehandle and put a reference to it in the first argument, like so:

      open( my $in, $infile )   or die "Couldn't read $infile: $!";
      while ( <$in> ) {
      # do something with $_
      }
      close $in;
  [download]

  Indirect filehandles make namespace management easier. Since filehandles are global to the current package, two subroutines trying to open INFILE will clash. With two functions opening indirect filehandles like my $infile, there's no clash and no need to worry about future conflicts. Another convenient behavior is that an indirect filehandle automatically closes when it goes out of scope or when you undefine it:

      sub firstline {
      open( my $in, shift ) && return scalar <$in>;
      # no close() required
      }
  [download]

• At the expense of legibility (although it is considered standard coding practice in Perl), you should use while(<AFH>) {...} and the line read in will be in the magical variable $_ on which both chomp, s/ / / and split work by default. As it is now, chomp has no effect on $line
• The argument to split is a bit complex. Are you perhaps trying to parse a CSV-style file? In that case you could think of using the Text::CVS_XS module
• drop the $sth1->bind_param(1, $niin); line. It serves no purpose here. As per the docs in DBI either you use bind_param to provide the data to be put in place of the "?" placeholder or you provide this data as an argument to execute

  bind_param

    $sth->bind_param($p_num, $bind_value)
    $sth->bind_param($p_num, $bind_value, \%attr)
    $sth->bind_param($p_num, $bind_value, $bind_type)
  [download]

  The bind_param method takes a copy of $bind_value and associates it (binds it) with a placeholder, identified by $p_num, embedded in the prepared statement. Placeholders are indicated with question mark character (?). For example:

    $dbh->{RaiseError} = 1;        # save having to check each method ca
  +ll
    $sth = $dbh->prepare("SELECT name, age FROM people WHERE name LIKE ?
  +");
    $sth->bind_param(1, "John%");  # placeholders are numbered from 1
    $sth->execute;
  [download]

• Add the usual or die ... after the $sth1->execute($row[0]) so you know what went wrong.

Things to note:

• "Create table" should be done using a "$dbh->do" type command
• You don't do a "$dbh->prepare('commit')", "$dbh->commit" is what you need

my $sth = $dbh->prepare($sql) or die $dbh->errstr();
# and
$sth->execute() or die $dbh->errstr();
[download]