| |
| |
| |
|
Page: 1 2 3 4 5
Comments:
<0> and... deadly
<1> and a sneaky little ****er
<2> and we say -erbs, where the british say herbs, because there's a ****ing "h" in it
<2> the h in herbs also stands for 'binary'
<3> b stands for big deal
<1> and a q and a p and a zed
<1> look, a word in scrabbel worth 9000 points
<3> cake
<2> well were OUTTA cake!~
<3> damnit
<0> yes, we only had 3 bits and didn't expect such a rush
<3> p*** me my blindfold please
<0> all I have is.... one made of sharks
<3> drat
<3> where can i find a data type mapping for sql server...
<2> pfft
<2> you know with a little encouragement we coulda done the whole damn thing
<2> but no, you have to bring up sql server
<3> yes. sql server.
<3> 'Ni'!!
<0> What is this 'mapping' you speak of? SQL data types to VB types?
<0> http://msdn2.microsoft.com/en-US/library/ms131092.aspx
<0> convert to vb6 where applicable
<3> i'm using adodb recordset for schema information on tables and building new queries based on that. I get a Fld.Type which is a number like 203. I need to convert that to the correct data type so output as text into the stored procedure parameters list.
<0> wanna see something really nifty?
<0> google "recordset field type"
<0> check the first hit
<3> ok that's it. except its useless.
<3> adLongVarWChar <-- that does not tell me anything useful.
<3> (for my purpose that is)
<0> It gives you the numeric value ***ociated with it
<0> which is, given you last question, what you were looking to map?
<3> I already have that. What I need is the SQL Server datatype that relates to each DataTypeEnum Constant.
<3> the adLongVarChar is not a sql server data type. its an ado enum.
<0> there may not be one
<0> SQL doesn't have a direct correspondence for some, such as "adChapter"
<3> good lord man.
<0> or adFileType, etc
<3> well you would think that there would be a mapping for datatypes that pertain to tables though.
<0> One could ***ume 'adLongVarWChar' would be a nvarchar
<0> let me put it this way
<3> ***ume. not where i like to be as a programmer. i need the info. throw me a bone here.
<0> There are more ADO constants than there are SQL Server data types
<3> those basturds
<0> adChapter does NOT correspond to an SQL Server field data type
<0> simple as that
<0> ADO is MORE than just SQL Server
<0> think backwards
<0> create a table that has one of each type of SQL Server field
<3> ok but all the ones in that list should correspond
<0> then, get the ad* constants for those
<0> The list in the link I gave you?
<3> yes
<0> no. because those are ADO constants
<3> those are all data type fields.
<0> not SQL server constants
<0> ADO handles more than just SQL server. ADO must handle many different databases
<3> shouldnt those correspond to sql server fields though?
<0> as such, there are more data types defined in ADO than in SQL Server
<0> does that not makessense?
<3> like the LongVarChar... that would presumably translate to 'text'
<0> perhaps
<0> it depends on the data in the field
<3> right... its the guesswork i'm trying to eliminate.
<0> In order to do that, you're going to have to ***ume to give the fields as wide a field as possible
<3> which is why i would like to find a mapping. so that when I get back from the schema 203 I know definitively that it is the 'text' data type.
<3> etc.
<0> Where did you originally get this value of 203?
<3> from a page much like the one you sent. off of msdn somewhere about four months ago.
<0> So you've never had a field that returned 203?
<3> it showed MS Access vs SQL data types.
<0> it may not, in any way shape or form, apply to SQL server
<3> plus a few others iirc
<3> I had at that point not yet experimented with using fields like the 'text' field.
<3> I am up to that now.
<0> Since there are items in the list (ADO field types) that do not have a direct correspondence to SQL Server field types, there will not always be a match
<0> You'regoing to have to either guess, or just be as safe as possible, even if that kills performance
<0> (like using text where varchar(2) would be more than enough)
<3> that's not a good position to be in.
<0> you may not have a choice
<3> confound that drated Darth Vendor!
<0> Because there is no 1:1 corrrespondence
<0> If something is string data, make it text
<3> yeah. ok. I can guess it out I guess.
<0> if it's numerical, make it decimal
<0> that's reletively safe
<3> ok
<3> that works for me
<3> thanks
<0> but not guarenteed
<3> understood.
<0> again, depends on the data in the 'original' field
<3> I won't sue you.
<0> Now why are you trying to do this 'conversion'?
<3> like I said, i have a utility that looks at tables and creates new stored procedures from the table data (and vb.net code to go with it).
<3> time saver device of mine.
<3> creates all my standard queries and code.
<3> from there the rest of the programming is usually fairly simple.
<0> mmkay, so you're pointing to a SQL Server table, and it generates code?
<3> yes and queries
<0> Let's say this table contains two fields: int and varchar(10)
<3> pumps the queries into the database and gens the cl*** code to go after them.
<0> So there's no issue here, actually
<0> you're using ONLY sql server, yes?
<3> or MS Access.
<0> ick
<0> let's stick with SQL for this example
<4> "database"
<0> Create a table that contains one field of every type
<0> point your doohickey at this table
<0> whatever numbers come out of the .Type corresponds to ADO's representation of that SQL Server data type
<3> yeah
<0> problem solved
<0> No guesswork needed period
<3> good solution.
<0> Don't try and find corresponding values to things that don't exist in SQL server at all
<3> you have a good brain on that sholder of yours.
<0> [15:25:17] <0> think backwards
<0> [15:25:24] <0> create a table that has one of each type of SQL Server field
<0> mr. timestamp :P
<0> do the smae for Access
<0> i'd suggest to keep two lists, actually. one for SQL server, one for access
<3> That's what I've got actually.
<3> two functions that return the data type name.
<3> one for MDB one for SQL
<0> given the id?
<3> given the numeric value of the fld.type
<0> Public ServerTypeEnum
<0> SQLServer = 1
<0> Access = 2
<0> End Enum
<0> Public Function GetFieldTypeName(id, ServerTypeEnum.SQLServer) As String
<0> now it's one function :P
<3> yeah ok. could do that. its not that big a deal.
<0> but it'd still be a big select/case either way
<3> exactly
<3> its easier to look at the two separate functions than one big'un
<0> fair enough
<3> anyway, that's good advice from Teycho #28272262. Thanks.
<3> I'll do that tonight and get it done with.
<0> Plz to insert $5 into teh slot.
<4> Teycho the talking slot machine.
<3> if IRC had a paypal setup... how rich would you guys get?
<3> $5 per question. my goodness. you guys could make a living.
<0> no, it'd be educational independent contractors
<0> that's in the $200/hr range
<0> So our next big goal at work is to train the 5 mainframe developers in .net
<0> the mere thought makes me cringe
Return to
#vb
or
Go to some related
logs:
#photoshop
/usr/src/kernels/2.6.15-1.2054_FC5-i586
gbind admin dalnet
Tone Loc Funky Cold Medina mp3
#allnitecafe
Daewoo Tricked Out
#vb
#india
#chat-world
#linux
|
|