A couple of memory management related questions
Locked
A couple of memory management related questions
 
|
Hi All,
I've started working on a new GC for Cog and have a few questions. 1. does anyone have a copy of Joel Bartlett's J. F. Bartlett. A generational, compacting collector for C++. In E. Jul and N.-C. Juul, editors, OOPSLA/ECOOP ‘90 Workshop on Garbage Collection in Object-Oriented Systems, Oct. 1990. ?
2. what's the largest number of classes you've got in your most complex image and/or what's the largest number of classes you're ever created in an image? a.k.a. is 64k classes enough (16 bits), or is 1m classes enough (24 bits)?
3. do you have any personal recommendations, or example code, of systems that combine generation scavenging and/or compaction with object pinning?
TIA, Eliot
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: A couple of memory management related questions
|
|
On 6/15/2010 5:17 PM, Eliot Miranda wrote: Hi All, -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@... Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [squeak-dev] A couple of memory management related questions
|
|
In reply to this post by Eliot Miranda-2
If people define classes by hand, I imagine 64k would be enough. But
suppose they are using light-weight classes, i.e. giving each object its own behavior. Then it would be fairly easy to have more than 64K of them, though 1M is still a reasonable limit. What is the difference in cost between choosing 64K as the limit and choosing 1M? I know, one byte, but what else would you use that byte for? -Ralph _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Eliot Miranda-2
Can't resist the following unproductive comment: Object pinning? Ugh!!
I realize you probably, after much thought, have decided you cannot avoid pinning, but its consequences scare the you-know-what out of me. If you supported one class per object, then you could get rid of the identityHash field in the header, by making it an instance method. ;-) Oh wait a minute, since classes are objects, you would need oops larger than 64-bits each. ;-) - David On Jun 15, 2010, at 2:17 PM, Eliot Miranda wrote: Hi All, _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [squeak-dev] A couple of memory management related questions
|
|
In reply to this post by Ralph Johnson
At Tue, 15 Jun 2010 16:44:57 -0500,
Ralph Johnson wrote: > > If people define classes by hand, I imagine 64k would be enough. But > suppose they are using light-weight classes, i.e. giving each object > its own behavior. Then it would be fairly easy to have more than 64K > of them, though 1M is still a reasonable limit. > > What is the difference in cost between choosing 64K as the limit and > choosing 1M? I know, one byte, but what else would you use that byte > for? If the next highest notch from 16 bit is 24 bit but not 20 bit, that would be 16M but not 1M. The big images in "our" use cases is with several million objects (not that big in other standard), so if each object theoretically had a distinct class, it would only barely fits. But in reality 16M classes and an object occupies around 40 byte each on avarage, only 6 instances or such per class on average before hitting 4GB. So, for 32-bit address space in mind, 16M classes would be a lot. 1M classes would be 100 instances on average (where the distribution of instance count is highly skewed so average would not make so much sense however), it still would be okay. (As Ralph asked, what are the other things that are competing the bits?) -- Yoshiki _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: A couple of memory management related questions
|
|
In reply to this post by Eliot Miranda-2
On Tue, Jun 15, 2010 at 2:17 PM, Eliot Miranda <[hidden email]> wrote: Hi All, thanks to all 5 of you who've provided this. Ta!
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: A couple of memory management related questions
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot,
> 2. what's the largest number of classes you've got in your most > complex image and/or what's the largest number of classes you're ever > created in an image? a.k.a. is 64k classes enough (16 bits), or is > 1m classes enough (24 bits)? 22708 and counting. So to me 64k seems a bit low as a hard limit. R - _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: A couple of memory management related questions
|
|
Dear Eliot,
like Reinout, I've never got to within 50% of 64,000 classes but I have known systems of 20,000+. Hence a system of 64,000 + 1 classes written by hand doesn't seem impossible, though the software wall (of complexity) makes me think you could survive quite some time with that limit if hand-written classes were your only concern. As Ralph points out, class generation schemes could blow you away. Ghost classes (a la JNIPort, etc.) might also: most of a 20,000+ class image are application classes and presumably the right (or do I mean wrong :-) ) ghost class system(s) could double or triple their number. Yours faithfully Niall Ross >Hi Eliot, > > >>2. what's the largest number of classes you've got in your most >>complex image and/or what's the largest number of classes you're ever >>created in an image? a.k.a. is 64k classes enough (16 bits), or is >>1m classes enough (24 bits)? >> >> > > 22708 and counting. > So to me 64k seems a bit low as a hard limit. > > >R >- > >_______________________________________________ >vwnc mailing list >[hidden email] >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: A couple of memory management related questions
|
|
In reply to this post by Eliot Miranda-2
Generating WS interfaces from WSDL for some larger companies might also rack up those numbers rather quickly. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: A couple of memory management related questions
|
|
On Thu, Jun 17, 2010 at 8:04 AM, Boris Popov, DeepCove Labs (YVR) <[hidden email]> wrote:
Agreed. On squeak-dev Andreas Raab said the following, which I'm going to follow: Cheers, - Andreas"
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Hi, The brochure states "VisualWorks supports connectivity via ODBC, and via native connections to Oracle, Sybase, SQL Server, PostgreSQL, and DB/2". I’ve installed the sqlncli.msi on the client machine, Windows XP w/ SP3. However, I can't seem to locate the right EXDI parcel within VW7.7 to connect to SQL Server 2008. What must I load to create a native sql connection to SQL Server? Any guidance would be much appreciated. Thank you, Linh _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: SQL Server Connection Parcel
|
|
I think the brochure is a bit brief. We
don’t have a ‘native’ SQL Server connection, with special
DLLs specified. Load ODBCEXDI, and use a plain ODBCConnection, which targets
SQL Server in particular. That said, there is the “SQL Server Native
Client”, which you can connect to with VisualWorks, using ODBC. VW
handles this in basically the same way as a regular ODBC client, with a few
checks here and there for known differences (which I don’t recall
offhand). You can connect using the native client by setting up your DSN using
the Windows Ctrl Panel/ODBC admin screen, and specifying the native client interface
to SQL Server. So, to VW, it’s almost completely
transparent whether you’re connecting using the old interface (via ODBC),
or using the new native client interface (also via ODBC). I hope this helps. - Dave From:
[hidden email] [mailto:[hidden email]] On Behalf Of Linh Dinh Hi, The brochure states "VisualWorks
supports connectivity via ODBC, and via native connections to Oracle, Sybase,
SQL Server, PostgreSQL, and DB/2". I’ve installed the
sqlncli.msi on the client machine, Windows XP w/ SP3. However, I can't
seem to locate the right EXDI parcel within VW7.7 to connect to SQL Server
2008. What must I load to create a native sql connection to SQL Server? Any guidance would be much appreciated. Thank you, Linh _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: SQL Server Connection Parcel
|
|
I would strongly recommend using connection strings instead of
DSNs as they make development/deployment a lot less complicated, DRIVER={SQL Native Client};DATABASE={my_database};SERVER={(local)}; Full reference is available here, http://msdn.microsoft.com/en-us/library/ms130822.aspx You can also have a look at a more complex solution in
GlorpVWLauncherTool package in Public Repository which enables reading of
settings from a local .ini file for even more flexibility, specifically GlorpTestingMiniTool
#availableLoginsIn: #readLogins and #help. HTH, -Boris -- DeepCove Labs Ltd. +1 (604) 689-0322 4th floor, 595 Howe Street Vancouver, British Columbia Canada V6C 2T5 http://tinyurl.com/r7uw4 PacNet Services (Europe) Ltd. +353 (0)61 714-360 Shannon Airport House, SFZ County Clare, Ireland http://tinyurl.com/y952amr CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender and
delete the entire message including any attachments. Thank you. From: [hidden email]
[mailto:[hidden email]] On Behalf Of Wallen, David I think the brochure is a bit brief. We don’t have a
‘native’ SQL Server connection, with special DLLs specified. Load ODBCEXDI,
and use a plain ODBCConnection, which targets SQL Server in particular. That
said, there is the “SQL Server Native Client”, which you can
connect to with VisualWorks, using ODBC. VW handles this in basically the same
way as a regular ODBC client, with a few checks here and there for known
differences (which I don’t recall offhand). You can connect using the
native client by setting up your DSN using the Windows Ctrl Panel/ODBC admin
screen, and specifying the native client interface to SQL Server. So, to VW, it’s almost completely transparent whether
you’re connecting using the old interface (via ODBC), or using the new
native client interface (also via ODBC). I hope this helps. - Dave From: [hidden email]
[mailto:[hidden email]] On Behalf Of Linh Dinh Hi, The brochure states
"VisualWorks supports connectivity via ODBC, and via native connections to
Oracle, Sybase, SQL Server, PostgreSQL, and DB/2". I’ve
installed the sqlncli.msi on the client machine, Windows XP w/ SP3.
However, I can't seem to locate the right EXDI parcel within VW7.7 to connect
to SQL Server 2008. What must I load to create a native sql connection to
SQL Server? Any guidance would be
much appreciated. Thank you, Linh _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: SQL Server Connection Parcel
|
|
Boris, this information is very useful. Thanks
for the url. - Dave From: I would strongly
recommend using connection strings instead of DSNs as they make
development/deployment a lot less complicated, DRIVER={SQL Native
Client};DATABASE={my_database};SERVER={(local)}; Full reference is
available here, http://msdn.microsoft.com/en-us/library/ms130822.aspx You can also have a
look at a more complex solution in GlorpVWLauncherTool package in Public
Repository which enables reading of settings from a local .ini file for even
more flexibility, specifically GlorpTestingMiniTool #availableLoginsIn:
#readLogins and #help. HTH, -Boris -- DeepCove Labs Ltd. +1 (604) 689-0322 4th floor, http://tinyurl.com/r7uw4 PacNet Services ( +353 (0)61 714-360 http://tinyurl.com/y952amr CONFIDENTIALITY
NOTICE This email is
intended only for the persons named in the message header. Unless otherwise
indicated, it contains information that is private and confidential. If you
have received it in error, please notify the sender and delete the entire
message including any attachments. Thank you. From:
[hidden email] [mailto:[hidden email]] On Behalf Of Wallen, David I think the brochure is a bit brief. We
don’t have a ‘native’ SQL Server connection, with special
DLLs specified. Load ODBCEXDI, and use a plain ODBCConnection, which targets
SQL Server in particular. That said, there is the “SQL Server Native
Client”, which you can connect to with VisualWorks, using ODBC. VW
handles this in basically the same way as a regular ODBC client, with a few
checks here and there for known differences (which I don’t recall
offhand). You can connect using the native client by setting up your DSN using
the Windows Ctrl Panel/ODBC admin screen, and specifying the native client
interface to SQL Server. So, to VW, it’s almost completely transparent
whether you’re connecting using the old interface (via ODBC), or using
the new native client interface (also via ODBC). I hope this helps. - Dave From:
[hidden email] [mailto:[hidden email]] On Behalf Of Linh Dinh Hi, The brochure states "VisualWorks
supports connectivity via ODBC, and via native connections to Oracle, Sybase,
SQL Server, PostgreSQL, and DB/2". I’ve installed the
sqlncli.msi on the client machine, Windows XP w/ SP3. However, I can't
seem to locate the right EXDI parcel within VW7.7 to connect to SQL Server
2008. What must I load to create a native sql connection to SQL Server? Any guidance would be much appreciated. Thank you, Linh _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: SQL Server Connection Parcel
|
|
In reply to this post by Linh Dinh
In fact connection string can reference DSN if you need that compatibility :)
-Boris (via BlackBerry) From: Wallen, David <[hidden email]> To: Boris Popov, DeepCove Labs (YVR); Linh Dinh <[hidden email]>; [hidden email] <[hidden email]> Sent: Fri Jun 18 15:16:51 2010 Subject: RE: [vwnc] SQL Server Connection Parcel Boris, this information is very useful. Thanks
for the url. - Dave From: I would strongly
recommend using connection strings instead of DSNs as they make
development/deployment a lot less complicated, DRIVER={SQL Native
Client};DATABASE={my_database};SERVER={(local)}; Full reference is
available here, http://msdn.microsoft.com/en-us/library/ms130822.aspx You can also have a
look at a more complex solution in GlorpVWLauncherTool package in Public
Repository which enables reading of settings from a local .ini file for even
more flexibility, specifically GlorpTestingMiniTool #availableLoginsIn:
#readLogins and #help. HTH, -Boris -- DeepCove Labs Ltd. +1 (604) 689-0322 4th floor, http://tinyurl.com/r7uw4 PacNet Services ( +353 (0)61 714-360 http://tinyurl.com/y952amr CONFIDENTIALITY
NOTICE This email is
intended only for the persons named in the message header. Unless otherwise
indicated, it contains information that is private and confidential. If you
have received it in error, please notify the sender and delete the entire
message including any attachments. Thank you. From:
[hidden email] [mailto:[hidden email]] On Behalf Of Wallen, David I think the brochure is a bit brief. We
don’t have a ‘native’ SQL Server connection, with special
DLLs specified. Load ODBCEXDI, and use a plain ODBCConnection, which targets
SQL Server in particular. That said, there is the “SQL Server Native
Client”, which you can connect to with VisualWorks, using ODBC. VW
handles this in basically the same way as a regular ODBC client, with a few
checks here and there for known differences (which I don’t recall
offhand). You can connect using the native client by setting up your DSN using
the Windows Ctrl Panel/ODBC admin screen, and specifying the native client
interface to SQL Server. So, to VW, it’s almost completely transparent
whether you’re connecting using the old interface (via ODBC), or using
the new native client interface (also via ODBC). I hope this helps. - Dave From:
[hidden email] [mailto:[hidden email]] On Behalf Of Linh Dinh Hi, The brochure states "VisualWorks
supports connectivity via ODBC, and via native connections to Oracle, Sybase,
SQL Server, PostgreSQL, and DB/2". I’ve installed the
sqlncli.msi on the client machine, Windows XP w/ SP3. However, I can't
seem to locate the right EXDI parcel within VW7.7 to connect to SQL Server
2008. What must I load to create a native sql connection to SQL Server? Any guidance would be much appreciated. Thank you, Linh _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: SQL Server Connection Parcel
|
|
Yep, I think I noticed that that would
override whatever else is mentioned, but I’m not sure. Now I’m curious about
other vendors, and how this technique works (for ODBC) with all the other guys?
If it’s generally available, then the ODBC Management console is obsolete for
me, except maybe when setting up a connection for the first time, trying to get
the settings right… - Dave From: In fact connection string can reference
DSN if you need that compatibility :) From: Wallen,
David <[hidden email]> Boris, this information is very useful.
Thanks for the url. - Dave From: I would strongly
recommend using connection strings instead of DSNs as they make
development/deployment a lot less complicated, DRIVER={SQL Native
Client};DATABASE={my_database};SERVER={(local)}; Full reference is
available here, http://msdn.microsoft.com/en-us/library/ms130822.aspx You can also have a
look at a more complex solution in GlorpVWLauncherTool package in Public
Repository which enables reading of settings from a local .ini file for even
more flexibility, specifically GlorpTestingMiniTool #availableLoginsIn:
#readLogins and #help. HTH, -Boris -- DeepCove Labs Ltd. +1 (604) 689-0322 4th floor, http://tinyurl.com/r7uw4 PacNet Services ( +353 (0)61 714-360 http://tinyurl.com/y952amr CONFIDENTIALITY
NOTICE This email is
intended only for the persons named in the message header. Unless otherwise
indicated, it contains information that is private and confidential. If you
have received it in error, please notify the sender and delete the entire
message including any attachments. Thank you. From:
[hidden email] [mailto:[hidden email]] On Behalf Of Wallen, David I think the brochure is a bit brief. We
don’t have a ‘native’ SQL Server connection, with special DLLs specified. Load
ODBCEXDI, and use a plain ODBCConnection, which targets SQL Server in
particular. That said, there is the “SQL Server Native Client”, which you can
connect to with VisualWorks, using ODBC. VW handles this in basically the same
way as a regular ODBC client, with a few checks here and there for known
differences (which I don’t recall offhand). You can connect using the native
client by setting up your DSN using the Windows Ctrl Panel/ODBC admin screen,
and specifying the native client interface to SQL Server. So, to VW, it’s almost completely
transparent whether you’re connecting using the old interface (via ODBC), or
using the new native client interface (also via ODBC). I hope this helps. - Dave From:
[hidden email] [mailto:[hidden email]] On Behalf Of Linh Dinh Hi, The brochure states "VisualWorks
supports connectivity via ODBC, and via native connections to Oracle, Sybase,
SQL Server, PostgreSQL, and DB/2". I’ve installed the sqlncli.msi on
the client machine, Windows XP w/ SP3. However, I can't seem to locate
the right EXDI parcel within VW7.7 to connect to SQL Server 2008. What
must I load to create a native sql connection to SQL Server? Any guidance would be much appreciated. Thank you, Linh _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: A couple of memory management related questions
|
|
In reply to this post by Niall Ross
Agreed. Consider a distributed object "database" in which an objectspace may contain instances from multiple versions of a class. The language could easily evolve that way over the next 10 years. Multiple class versions is a standard GS/S feature, but a more distributed form of object database could greatly increase that number. 64K is far more than our anticipated needs though. Metaclass allInstances size 7241 That number includes GS classes mirrored in VW by GemKit. Paul Baumann -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Niall Ross Sent: Thursday, June 17, 2010 11:02 AM To: vwnc NC Subject: Re: [vwnc] A couple of memory management related questions Dear Eliot, like Reinout, I've never got to within 50% of 64,000 classes but I have known systems of 20,000+. Hence a system of 64,000 + 1 classes written by hand doesn't seem impossible, though the software wall (of complexity) makes me think you could survive quite some time with that limit if hand-written classes were your only concern. As Ralph points out, class generation schemes could blow you away. Ghost classes (a la JNIPort, etc.) might also: most of a 20,000+ class image are application classes and presumably the right (or do I mean wrong :-) ) ghost class system(s) could double or triple their number. Yours faithfully Niall Ross >Hi Eliot, > > >>2. what's the largest number of classes you've got in your most >>complex image and/or what's the largest number of classes you're ever >>created in an image? a.k.a. is 64k classes enough (16 bits), or is >>1m classes enough (24 bits)? >> >> > > 22708 and counting. > So to me 64k seems a bit low as a hard limit. > > >R >- > >_______________________________________________ >vwnc mailing list >[hidden email] >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Wallen, David
Hi, Thanks to David and Boris, I was ecstatic when I learned we didn't have to create a DSN to connect to SQL Server. However, I’m running into a wall trying to get the Lens framework to connect to SQL Server. I have searched the entire vw7.7 folder but it doesn’t appear there is a Lens parcel for SQL Server. There are Lens parcel for Sybase, Oracle, DB2 in the c:\vw7.7\database folder but nothing for SQL Server. I’ve tried Google for the Lens framework support for SQL Server but it didn’t return any useful link. How do I go about creating a Lens Data Modeler for SQL Server? Thanks, Linh From: "Wallen, David" <[hidden email]> To: "Boris Popov, DeepCove Labs (YVR)" <[hidden email]>; [hidden email]; [hidden email] Sent: Fri, June 18, 2010 3:32:46 PM Subject: RE: [vwnc] SQL Server Connection Parcel Yep, I think I noticed that that would override whatever else is mentioned, but I’m not sure. Now I’m curious about other vendors, and how this technique works (for ODBC) with all the other guys? If it’s generally available, then the ODBC Management console is obsolete for me, except maybe when setting up a connection for the first time, trying to get the settings right… - Dave
From: Boris Popov , DeepCove Labs (YVR) [mailto:[hidden email]]
In fact connection string can reference DSN if you need that compatibility :)
From: Wallen, David <[hidden email]> Boris, this information is very useful. Thanks for the url.
- Dave
From: Boris Popov , DeepCove Labs (YVR) [mailto:[hidden email]]
I would strongly recommend using connection strings instead of DSNs as they make development/deployment a lot less complicated,
DRIVER={SQL Native Client};DATABASE={my_database};SERVER={(local)};
Full reference is available here,
http://msdn.microsoft.com/en-us/library/ms130822.aspx
You can also have a look at a more complex solution in GlorpVWLauncherTool package in Public Repository which enables reading of settings from a local .ini file for even more flexibility, specifically GlorpTestingMiniTool #availableLoginsIn: #readLogins and #help.
HTH,
-Boris
-- DeepCove Labs Ltd. +1 (604) 689-0322 4th floor, 595 Howe Street Vancouver, British Columbia Canada V6C 2T5 http://tinyurl.com/r7uw4
PacNet Services ( Europe ) Ltd. +353 (0)61 714-360 Shannon Airport House, SFZ County Clare, Ireland http://tinyurl.com/y952amr
CONFIDENTIALITY NOTICE
This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments.
Thank you.
From: [hidden email] [mailto:[hidden email]] On Behalf Of Wallen, David
I think the brochure is a bit brief. We don’t have a ‘native’ SQL Server connection, with special DLLs specified. Load ODBCEXDI, and use a plain ODBCConnection, which targets SQL Server in particular. That said, there is the “SQL Server Native Client”, which you can connect to with VisualWorks, using ODBC. VW handles this in basically the same way as a regular ODBC client, with a few checks here and there for known differences (which I don’t recall offhand). You can connect using the native client by setting up your DSN using the Windows Ctrl Panel/ODBC admin screen, and specifying the native client interface to SQL Server.
So, to VW, it’s almost completely transparent whether you’re connecting using the old interface (via ODBC), or using the new native client interface (also via ODBC). I hope this helps.
- Dave
From: [hidden email] [mailto:[hidden email]] On Behalf Of Linh Dinh
Hi,
The brochure states "VisualWorks supports connectivity via ODBC, and via native connections to Oracle, Sybase, SQL Server, PostgreSQL, and DB/2". I’ve installed the sqlncli.msi on the client machine, Windows XP w/ SP3. However, I can't seem to locate the right EXDI parcel within VW7.7 to connect to SQL Server 2008. What must I load to create a native sql connection to SQL Server?
Any guidance would be much appreciated.
Thank you, Linh
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: SQL Server Connection Parcel
|
|
The Lens framework is pretty old, and I would suggest you'd
be better off using Glorp. In terms of nice tools for it, there isn't
anything in VisualWorks, but you could use the ObjectStudio mapping tool,
which should produce code compatible with VisualWorks, or Web Velocity,
which does likewise. They won't be as nice for automatically making
VisualWorks UI's, but are significantly more powerful and up to
date.
At 08:20 PM 2010-06-23, Linh Dinh wrote: Hi,From: "Wallen, David" <[hidden email]> To: "Boris Popov, DeepCove Labs (YVR)" <[hidden email]>; [hidden email]; [hidden email] Sent: Fri, June 18, 2010 3:32:46 PM Subject: RE: [vwnc] SQL Server Connection Parcel Yep, I think I noticed that that would override whatever else is mentioned, but Iâm not sure. Now Iâm curious about other vendors, and how this technique works (for ODBC) with all the other guys? If itâs generally available, then the ODBC Management console is obsolete for me, except maybe when setting up a connection for the first time, trying to get the settings right - Dave Sent: Friday, June 18, 2010 3:21 PM To: Wallen, David; [hidden email]; [hidden email] Subject: Re: [vwnc] SQL Server Connection Parcel In fact connection string can reference DSN if you need that compatibility :) -Boris (via BlackBerry) From: Wallen, David <[hidden email]> To: Boris Popov , DeepCove Labs (YVR); Linh Dinh <[hidden email]>; [hidden email] <[hidden email]> Sent: Fri Jun 18 15:16:51 2010 Subject: RE: [vwnc] SQL Server Connection Parcel Boris, this information is very useful. Thanks for the url. - Dave Sent: Friday, June 18, 2010 6:22 AM To: Wallen, David; Linh Dinh; [hidden email] Subject: RE: [vwnc] SQL Server Connection Parcel I would strongly recommend using connection strings instead of DSNs as they make development/deployment a lot less complicated, DRIVER={SQL Native Client};DATABASE={my_database};SERVER={(local)}; Full reference is available here, http://msdn.microsoft.com/en-us/library/ms130822.aspx You can also have a look at a more complex solution in GlorpVWLauncherTool package in Public Repository which enables reading of settings from a local .ini file for even more flexibility, specifically GlorpTestingMiniTool #availableLoginsIn: #readLogins and #help. HTH, -Boris -- DeepCove Labs Ltd. +1 (604) 689-0322 4th floor, 595 Howe Street Vancouver, British Columbia Canada V6C 2T5 http://tinyurl.com/r7uw4 PacNet Services ( Europe ) Ltd. +353 (0)61 714-360 Shannon Airport House, SFZ County Clare, Ireland http://tinyurl.com/y952amr CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. From: [hidden email] [[hidden email]] On Behalf Of Wallen, David Sent: 18 June 2010 08:24 To: Linh Dinh; [hidden email] Subject: Re: [vwnc] SQL Server Connection Parcel I think the brochure is a bit brief. We donât have a ânativeâ SQL Server connection, with special DLLs specified. Load ODBCEXDI, and use a plain ODBCConnection, which targets SQL Server in particular. That said, there is the âSQL Server Native Clientâ, which you can connect to with VisualWorks, using ODBC. VW handles this in basically the same way as a regular ODBC client, with a few checks here and there for known differences (which I donât recall offhand). You can connect using the native client by setting up your DSN using the Windows Ctrl Panel/ODBC admin screen, and specifying the native client interface to SQL Server. So, to VW, itâs almost completely transparent whether youâre connecting using the old interface (via ODBC), or using the new native client interface (also via ODBC). I hope this helps. - Dave Sent: Thursday, June 17, 2010 7:58 PM To: [hidden email] Subject: [vwnc] SQL Server Connection Parcel Hi, The brochure states "VisualWorks supports connectivity via ODBC, and via native connections to Oracle, Sybase, SQL Server, PostgreSQL, and DB/2". Iâve installed the sqlncli.msi on the client machine, Windows XP w/ SP3. However, I can't seem to locate the right EXDI parcel within VW7.7 to connect to SQL Server 2008. What must I load to create a native sql connection to SQL Server? Any guidance would be much appreciated. Thank you, Linh _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
| Free forum by Nabble | Edit this page |