Why doesn't linqpad display all the columns in a table? - linqpad

I am using Windows Authentication to connect to a SQL-SERVER database.
I am using version 4.47.02 of Linqpad.
If you see the attached image, the same table in Sql server has more columns than the columns displayed in Linqpad.
EDIT: The columns that do not get displayed have a UDT for a data type.
How can I get all the columns in linqpad?

LINQPad supports user-defined data type aliases, but not user-defined CLR types. The latter is not easy to deal with, as suggested by the link that Chris posted.

Related

How to retrieve system object code or definition in SQL Server?

Hi i am using SQL Server 2012. i would like to view the system objects code/definition. can we view the system objects definition/code in SQL Server any version ?
wanted to know when i execute this query SELECT MONTH(18/200), MONTH(200/18) i am getting output 1 for both just want to know internal code what is going on and how it is giving output 1 for MONTH(200/18) ? to understand this looking for MONTH() function code.
Use INFORMATION_SCHEMA
An information schema view is one of several methods SQL Server
provides for obtaining metadata.
Information schema views provide an
internal, system table-independent view of the SQL Server metadata.
Information schema views enable applications to work correctly
although significant changes have been made to the underlying system
tables.
The information schema views included in SQL Server comply
with the ISO standard definition for the INFORMATION_SCHEMA.
answer to SELECT MONTH(18/200), MONTH(200/18) is any integer to the MONTH() interprets 0 as January 1, 1900. that's whey it is returning 1 1 as output.

Access cross-platform schema Report Builder

I'm working on some reports and we're halfway through migrating from Oracle to SQL Server.
The reports I'm migrating are using some user-defined functions from the Oracle schema so the rest of my new translated code obviously does not work with them.
Within Report Builder 3.0 I have access to the data source, how can I provide access to the schema so the functions still work?
I'm sorry if that isn't very clear.
I would try to build a dataset pointed at the Oracle schema that calls the user-defined functions and returns their results, together with the input parameter column(s). This dataset will need to return a row for every required combination of input parameter column(s).
Then in textbox expressions, I would use the SSRS Lookup function to return the function results from the Oracle dataset.

Are table names in query case-insensitive?

I have read the following article. They have quoted that,
SQL Server is a case-sensitive back-end application. This means that a
table named "addr" is distinguished from a table named "ADDR."
However, because Microsoft Query is an MS-DOS-based application, it is
unable to distinguish cases; therefore, Microsoft Query views "addr"
and "ADDR" as the same file.
Now I wanted to know what to they mean by case-sensitive back-end application? Is it safe to use the query with case-insensitivity?
Thanks in advance.
SQL Server with default collation will return you the same result, doesn't matter which case you use for your query.
Collation can be set at various levels
Server
Database
Column
For more info can be found out here
Please check Applies To section of the article you referenced. KB article applies to product from Microsoft for which they no longer provide any support.

UNDEFINED data type when reading SQL database from Lotus Notes using ODBC: nvarchar

This is the second time it happens to me and before modifying a 3rd party Database structure I wanted to know if anyone knew a better solution:
I'm accessing a MS SQL Server 2008 from a Lotus Notes Agent (Notes 7) to retrieve some data. I use LSXODBC and my "Select" statement works perfect... Except that my agent cannot "understand" Nvarchar SQL Field types. Any other data types work ok (can get the values from number and dates fields without a problem).
It took me a while to figure it out, and I couldn't find a solution (other than modifying the field types on the SQL table to Varchar instead of nVarchar)
I could replicate this both in MS SQL 2005 and 2008.
Last "elegant" solution was to create an SQL view -instead of modifying table structure- with the varchar types instead of nvarchar. Works ok but I have to create a view for each table I'm retrieving data from.
I tried to set the Field type using FieldExpectedDataType Method but didn't work. Still got a DB_TYPE_UNDEFINED.
I thought there might be some configuration issues? or maybe I'm using an old LN Version / ODBC Driver version?
Any hint would be greatly appreciated.
Thank you in advance.
Diego
An old ODBC driver may not support unicode. It was not added until SQL Server 2000 (I'm fairly sure)

Field types available for use with "CREATE TABLE" in Microsoft Access

I have the displeasure of generating table creation scripts for Microsoft Access. I have not yet found any documentation describing what the syntax is for the various types. I have found the documentation for the Create Table statement in Access but there is little mention of the types that can be used. For example:
CREATE TABLE Foo (MyIdField *FIELDTYPE*)
Where FIELDTYPE is one of...? Through trial and error I've found a few like INTEGER, BYTE, TEXT, SINGLE but I would really like to find a page that documents all to make sure I'm using the right ones.
I've found the table in the link below pretty useful:
http://allenbrowne.com/ser-49.html
It lists what Access's Gui calls each data type, the DDL name, DAO name and ADO name (they are all different...).
Some of the best documentation from Microsoft on the topic of SQL Data Definition Language (SQL DDL) for ACE/Jet can be found here:
Intermediate Microsoft Jet SQL for Access 2000
Of particular interest are the synonyms, which are important for writing portable SQL code.
One thing to note is that the Jet 4.0 version of the SQL DDL syntax requires the interface to be in ANSI-92 Query Mode; the article refers to ADO because ADO always uses ANSI-92 Query Mode. The default option for the MS Access interface is ANSI-89 Query Mode, however from Access2003 onwards the UI can be put into ANSI-92 Query Mode. All versions of DAO use ANSI-89 Query Mode. I'm not sure whether SQL DDL syntax was extended for ACE for Access2007.
For more details about query modes, see
About ANSI SQL query mode (MDB)
This has it all. It's direct from MS, and actually tells you what the SQL datatype is that correlates to the GUI name.