For SQL Server stay away from standard tables and injected SQL (permissions problems arise) and either go straight to the ADO connection object or use TADoStoredProcedure (I think is what its called). Check your collation and make sure its latin-8 or some other NON-case sensitive version.

You should also run a test and make sure that all of your properties or field names are initialized and populating properly, here is some basic code that I use in one project that's been modified to be used as a debug routine:
Code:
 FProc := TADOStoredProc.Create(nil);
 FProc.Connection := GetGlobalConnection;
 FProc.ProcedureName := 'YourProcedureNameGoesHere';
 i := 0;
 FProc.Parameters.Refresh;
 while(i<FProc.Parameters.Count)do
  begin
   Memo1.Lines.Text.Add(FProc.Parameters[i].Name);
   inc(i);
  end;
As for migrating from one DB to another, its much faster to script out your SyBase schema and data (separately as a CSV) and then use Bulk Insert (or similar) to do the actual import. Make sure you have proper unique identifiers and keys on EVERY table even if you don't think it needs one. This way you can rebuild your links by looking at the origin key and the new key then binding those instead of the origin (extremely fast if done properly). You can also still use the origin if you need to.

BTW: The reason your SyBase tables probably have VarChar indexes is a version thing. I don't remember exactly what version, but way back about v3 (when SQL Server and SyBase were the same product, because MS hadn't bought out the SyBase codebase yet) this was the "way to do it". I'd have to say your working on some very old code.

PS: If this isn't a personal project and is well funded I can recommend some high end consultants that do this type of stuff daily. Best in the biz as far as I'm concerned.

- Jeremy