Have you edited your SQL.ini (in Apple/Sybase/ini) file to point to you server?
j.
Wayne Morrison wrote:
>
> Was: problem with accessing Sybase from EOF 2.0 / OS 4.1 (listed in 1997)
>
> Just had the following exception raised inexplicably and, having searched the
>archive, I found nothing useful so I thought I'd send the email just so it is present:
>
> Mar 09 19:04:21 BatchScheduler[987] *** Uncaught exception:
><EOGeneralAdaptorException> Sybase: ct_connect(): network packet layer: internal net
>library error: Specified server name attribute could not be found
> stack: 0x18067c81 0x18067b3a 0x5087612 0x508785d 0x18064c23 0x1e007939 0x1e008f7b
>0x1e00971a 0x18253 0xd5ca 0xd56d 0x36ed 0x34fe
> exiting!
>
> The reason for it is partly our own fault, but also partly due to unforseen
>framework loading behaviour. The reason for it being our own fault is that we
>actually "blank" the connection dictionary of all eomodels and make a request to a
>default login database to use a specific enterprise database. From this point
>forward, all eomodels are loaded with the connection dictionary obtained from this
>login db.
>
> The second point, regarding framework loading behaviour, is that prior to accessing
>the default login db, we access a seemingly innocuous class of an external framework
>which, when loaded, initialises EOEditingContexts inside +initialize methods of other
>classes in the framework which, of course, require the database and so the whole
>thing crashes.
> The code resembled that below...
> int main () { //Innocuous method call that lazily loads SybaseAdaptor framework
>//due to the use of EOEditingContexts inside +initialize methods. [AClass
>setCurrentDate:[environment date]];
> //Login to the database according to the proposed name. Switching //these two lines
>around ensures the connection dictionary is set prior //to the lazy loading of
>SybaseAdaptor.framework. [DefaultLogin login:dbname]; ... }
>
> Wayne
--
Jeff Fedor | Annex Multimedia
