Ruby 1.9.2-head With RubyODBC 0.99991
Ken Collins
Have any of you all failed at this yet? I was just setting up RVM (finally) for
testing the adapter and other code and could not get ruby odbc to work on
the latest 1.9.2 head. Errors like:
dyld: lazy symbol binding failed: Symbol not found: _STR2CSTR
Referenced from: ~/.rvm/rubies/ruby-1.9.2-head/lib/ruby/site_ruby/1.9.1/x86_64-darwin10.4.0/odbc.bundle
Expected in: flat namespace
dyld: Symbol not found: _STR2CSTR
Referenced from: ~/.rvm/rubies/ruby-1.9.2-head/lib/ruby/site_ruby/1.9.1/x86_64-darwin10.4.0/odbc.bundle
Expected in: flat namespace
I sent an email to the author of the ruby odbc library. Will let you know if I find something out.
- Ken
KD.Gun...@zwick-edelstahl.de
yes support for STR2CSTR was removed. See:
http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=rev&revision=21920
Christian has already modified his code in ruby-odbc 0.99992
I have this code here for testing, but found another bug, so he didn't
released this version
Greetings
Klaus
Ken Collins
Ken Collins
Cool, like which bug? Can you post some info?
- Ken
On Jul 23, 2010, at 10:52 AM, KD.Gun...@Zwick-Edelstahl.de wrote:
> Hi Ken,
KD.Gun...@zwick-edelstahl.de
and you access a column of type ntext
then the adapter tries to allocate 1 GB ....
this may work on a production system with several gigs of ram
but failed on my VM with only 600 MB ;-))
On 23 Jul., 16:57, Ken Collins <k...@metaskills.net> wrote:
> Cool, like which bug? Can you post some info?
>
> - Ken
>
Ken Collins
FYI, I just tested this against these rubies and everything is looking good so far. I have some load path issues unrelated to ODBC. In general I am not seeing any memory bloat on my end.
ruby-1.8.6-p388 [ x86_64 ]
ruby-1.8.7-p299 [ x86_64 ]
ruby-1.9.1-p378 [ x86_64 ]
ruby-1.9.2-head [ x86_64 ]
BTW, did you see this article I just published about RubyODBC w/utf8?
http://metaskills.net/2010/7/19/a-macport-rubyodbc-update
In short, it is not needed. Frankly, I am not even sure it is safe since it advertises that it would return all strings as UTF8. Either way, once I learned the +utf8 variant was never actually _ever_ installed for me, I found out that I still can not even get it installed to test it. Moot tho since national/unicode data types are utf8 returned anyway in the main ODBC.
- Ken
> --
> You received this message because you are subscribed to the Google Groups "Rails SQLServer Adapter" group.
> To post to this group, send email to rails-sqlse...@googlegroups.com.
> To unsubscribe from this group, send email to rails-sqlserver-a...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rails-sqlserver-adapter?hl=en.
>
Ken Collins
Another update. Just tested 0.99992pre3 with positive results too.
- Ken
KD.Gun...@zwick-edelstahl.de
could you do me a favor and try to run this test in
unicode_test_sqlserver on your system :
should 'have the right length with utf8 data' do
assert data = SqlServerUnicode.create!(:nvarchar =>
@unicode_data)
read_data =
SqlServerUnicode.find_by_nvarchar(@unicode_data, :select => "nvarchar,
len(nvarchar) AS nvc_length ")
assert_equal @encoded_unicode_data.length , read_data.nvc_length
end
Ken Collins
Which ruby?
KD.Gun...@zwick-edelstahl.de
Ken Collins
Klaus,
Check out my latest "uniqueness_validation_test_sqlserver.rb" file. What I have found is that the #length of a unicode string is what the db limit will have to accommodate. From within ruby if you want the human length, you can use the #mb_chars proxy. Besides using the encoded binary data, you can write a test like that one I just did and come up with better results. If not or if I missed the point, lemme know.
- Ken
On Jul 26, 2010, at 7:53 AM, KD.Gun...@Zwick-Edelstahl.de wrote: