I've hit a brick wall on this issue and I can't seem to find or work out what is going wrong or find an answer to my problem ... I'm totally new to querying Active Directory, so I am hoping I've not done something that will warrant slapping my forehead when points me towards the solution!
So, I've uploaded images into both thumbnailPhoto and jpegPhoto and I can see in ADSI Edit that these do have a value.
I've set up a linked server (named ActiveDirectory) on our 2008 R2 Database Server and I can successfully query this and return results. If I run the query below, it returns the values fine, but once I uncomment the jpegPhoto line (commented out in the code below), I get the error ...
Cannot get the data of the row from the OLE DB provider "ADSDSOObject" for linked server "ActiveDirectory". Could not convert the data value due to reasons other than sign mismatch or overflow.
The query runs correctly with jpegPhoto uncommented if the contents of that field are never populated in the returning result set.
SELECT
objectGUID
,cn
,thumbnailPhoto
-- ,jpegPhoto
FROM OpenQuery (
ActiveDirectory,
'SELECT
objectGUID
,cn
,thumbnailPhoto
,jpegPhoto
FROM ''LDAP://XXXXX/OU=XXXXX,DC=XXXXX,DC=XXXXX,DC=com''
') AS AD
WHERE cn = 'username'
It seems strange to me that the result can be returned from the OpenQuery (I've tried OpenRowset to no avail), it fails outside of that it seems.
I have also tried all manner of CAST and CONVERT, but I'm at a loss now as to how I can actually get the contents of this field returned in my query (which I am just attempting to run in SQL Server Management Studio.
Has anyone come across this issue and overcome it?
I'm definitely hoping so!!
Thanks in advance!!
Gannon
Old issue I know but for those finding this on the googles.
As far as I can tell, for thumbnailPhoto, OLE DB Provider for Microsoft Directory Services is limited to 4k field sizes. This means if you upload a teenytiny photo, it works.
For jpegPhoto, there is a difference in the field type -
thumbnailPhoto is single valued and has a upper-Range of 102400 bytes.
jpegPhoto on the other hand is multivalued and doesn’t enforce an upper-Range
And, according to other pages on the internet -
The ADSI provider for SQL Server is rather limited - not supporting multi-valued attributes is one of those limitations.
Related
I want to export the data from a table from linked server. The table has over 300,000 rows.
When I run this query:
SELECT *
FROM [LSERVER].[LTechnologies].[Connector].[MASD]
I get an error:
OLE DB provider 'MSDASQL' for linked server 'LSERVER' returned data that does not match expected data length for column '[LSERVER].[LTechnologies].[Connector].[MASD]'. The (maximum) expected data length is 8000, while the returned data length is 8448.
The source is NetSuite linked to MS SQL as ODBC Data Source.
Is there any way to work around this limitation?
Thanks
Is there any way to work around this limitation?
The typical workaround is to use OPENQUERY to send a "passthrough" query to the target system and ask it to perform type conversions to the types that actually work.
Haim, it sounds like a built limitation limiting varchar or nvarchar to 8K characters. I have seen this a couple times but never seen anyone beat it - normally we just exclude the column. However if it's worth the time, you could find the column and do a LEFT([column], 7999) to see if you can at least get most of the data back. Hope it helps.
We are using Simba Mongo ODBC driver to connect to Mongo database and make sql queries. I tested connection on Linux using isql and was able to perform queries.
When my client tried to connect to Mongo through Microsoft SQL Server Management Studio he received the following error:
OLE DB provider 'MSDASQL' for linked server 'mongo' returned data that does not match
expected data length for column '[MSDASQL].contributorComposite__0__biographicalNote'.
The (maximum) expected data length is 255, while the returned data length is 290.
I've never worked with this application. Have you got any idea where I can control expected data length?
Linked Server is very picky about metadata and the data that is returned, in general you're more likely to encounter problems if your defined metadata doesn't match exactly what is expected when using it vs. using other applications.
What's happening in this case is that you're retrieving data with a string column defined. The data in the string column has a length of 290, but the driver is reporting a length of 255. This is because MongoDB doesn't return metadata about the length of any specific field as it is a schema-less data source. The driver instead uses a default for reporting lengths of string columns, which by default is set to 255. You can change this by opening the Configuration Dialog for the DSN, going to the Advanced Options, and changing the Standard string column length from 255 to something larger, like 512. This should allow Linked Server to behave properly unless your data exceeds 512 bytes, in which case you should simply adjust this to a larger appropriate value.
I found this answer here: One way to get around this problem is to construct your SQL statement, such as:
declare #myStmt varchar(max)
set #myStmt = 'select * from my_collection'
EXECUTE (#myStmt) AT MongoDB_PROD_mydb
I did try it myself on a linked SQLite server and it worked but the strange part is that on longer entries the text get cut off somewhat randomly. I have not figured this part out yet - it might have something to do with SQLiteODBC driver I'm using.
But the error of "expected data length" is handled.
Michael
I have a SQL Server 2008 database linked to an Access 2010 front end.
Some of the columns are varchar of varying lengths, from 50 to MAX. There is no default value and they can be null.
Recently, any of these columns longer than 255 started causing the write conflict error:
This record has been changed by another user since you started editing it. If you save the record, you will...
I can update other data, including varchar data, in the same row, with no problems and no errors.
This error occurs when I attempt to update the column directly from my table. It also occurs if I update the table programmatically via VBA or through a form.
It looks like this is because the column is NULL in SQL Server, but I've never seen this before with varchar columns. Is this a "feature" or a thing you just have to work around? It just started happening regardless, which is also confusing.
The leading cause of updatability problems in Office Access–linked tables is that Office Access is unable to verify whether data on the server matches with what was last retrieved by the dynaset being updated. If Office Access cannot perform this verification, it assumes that the server row has been modified or deleted by another user and it aborts the update.
There are several types of data that Office Access is unable to check reliably for matching values. These include large object types, such as text, ntext, image, and the varchar(max)(which is in your case), nvarchar(max), and varbinary(max) types.
Coming to your situation,i believe access forms may be bound to the data & produce a lot of locks on records and tables of SQL Server, those locks can prevent tables to be updated.So try to rectify Access forms which are bound to data and that are showing those updateability errors and make them work with unbound data, which allows you to read and update that unbound data to users without creating locks on the database server.
I'm attempting to run a simple statement against an Access DB to find records.
Data validation in the records was horrible, and I cannot sanitize it. Meaning, it must be preserved as is.
I need to be able to search against a string with white space and hyphen characters removed. The following statement will work in Access 2010 direct:
select * from dummy where Replace(Replace([data1],' ',''),'-','') = 'ABCD1234';
Running it from an ODBC connection via PHP will not. It produces the following error:
SQL error: [Microsoft][ODBC Microsoft Access Driver] Undefined function 'Replace' in expression., SQL state 37000 in SQLExecDirect
Creating a query in the database that runs the function and attempting to search its values indirectly causes the same error:
select * from dummy_indirect where Expr1 = 'ABCD1234';
I've attempted to use both ODBC drivers present. ODBCJR32.dll (03/22/2010) and ACEODBC.dll (02/18/2007). To my knowledge these should be current as it was installed with the full Access 2010 and Access 2010 Database Engine.
Any ideas on how to work around this error and achieve the same effect are welcome. Please note, that I cannot alter the database in way, shape, or form. That indirect query was created in another mdb file that has the original tables linked from the original DB.
* Update *
OleDB did not really affect anything.
$dsn= "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=c:\dummy.mdb;";
I'm not attempting to use it as a web backend either. I'm not a sadomasochist.
There is a legacy system that I must support that does use Access as a backend. Data gets populated there from other old systems that I must integrate into more modern systems. Hence, the creation of an API with Apache/PHP that is running on the server supporting the legacy system.
I need to be able to search a table that has an alphanumeric case identifier to get a numeric identifier that is unique and tied to a generator (Autonumber in access). Users have been using it a trash box for years (inconsistent data entry with sporadic notations) so the only solution I have is to strip everything except alphanumeric out of both the field value and the search value and attempt to perform a LIKE comparison against it.
If not replace() which is access supported, what ODBC compatible functions exist that I can use do the same kind of comparison?
Just to recap, the Access db engine will not recognize the Replace() function unless your query is run from within an Access application session. Any attempt from outside Access will trigger that "Undefined function" error message. You can't avoid the error by switching from ODBC to OleDb as the connection method. And you also can't trick the engine into using Replace() by hiding it in separate query (in the same or another Access db) and using that query as the data source for your main query.
This behavior is determined by Access' sandbox mode. That linked page includes a list of functions which are available in the default sandbox mode. That page also describes how you can alter the sandbox mode. If you absolutely must have Replace() available for your query, perhaps the lowest setting (0) would allow it. However, I'm not recommending you do that. I've never done it myself, so don't know anything about the consequences.
As for alternatives for Replace(), it would help to know about the variability in the values you're searching. If the space or dash characters appear in only one or a few consistent positions, you could do a pattern match with a Like expression. For example, if the search field values consist of 4 letters, an optional space or dash, followed by 4 digits, a WHERE clause like this should work for the variations of "ABCD1234":
SELECT * FROM dummy
WHERE
data1 = 'ABCD1234'
OR data1 Like 'ABCD[- ]1234';
Another possibility is to compare against a list of values:
SELECT * FROM dummy
WHERE
data1 IN ('ABCD1234','ABCD 1234','ABCD-1234');
However if your search field values can include any number of spaces or dashes at any position within the string, that approach is no good. And I would look real hard for some way to make the query task easier:
You can't clean the stored values because you're prohibited from altering the original Access db in any way. Perhaps you could create a new Access db, import the data, and clean that instead.
Set up the original Access db as a linked server in SQL Server and build your query to take advantage of SQL Server features.
Surrender. :-( Pull in a larger data set to your PHP client code, and evaluate which rows to use vs. which to ignore.
I'm not sure you can do this with ODBC and your constraints. The MS Access driver is limited (by design; MS wants you to use SQL Server for back ends).
Can you use OLEDB? that might be an option.
I've hit a bit of an impasse. I have a query that is generated by some C# code. The query works fine in Microsoft SQL Server Management Studio when run against the same database.
However when my code tries to run the same query I get the same error about an invalid column and an exception is thrown. All queries that reference this column are failing.
The column in question was recently added to the database. It is a date column called Incident_Begin_Time_ts .
An example that fails is:
select * from PerfDiag
where Incident_Begin_Time_ts > '2010-01-01 00:00:00';
Other queries like Select MAX(Incident_Being_Time_ts); also fail when run in code because it thinks the column is missing.
Any ideas?
Just press Ctrl + Shift + R and see...
In SQL Server Management Studio, Ctrl+Shift+R refreshes the local cache.
I suspect that you have two tables with the same name. One is owned by the schema 'dbo' (dbo.PerfDiag), and the other is owned by the default schema of the account used to connect to SQL Server (something like userid.PerfDiag).
When you have an unqualified reference to a schema object (such as a table) — one not qualified by schema name — the object reference must be resolved. Name resolution occurs by searching in the following sequence for an object of the appropriate type (table) with the specified name. The name resolves to the first match:
Under the default schema of the user.
Under the schema 'dbo'.
The unqualified reference is bound to the first match in the above sequence.
As a general recommended practice, one should always qualify references to schema objects, for performance reasons:
An unqualified reference may invalidate a cached execution plan for the stored procedure or query, since the schema to which the reference was bound may change depending on the credentials executing the stored procedure or query. This results in recompilation of the query/stored procedure, a performance hit. Recompilations cause compile locks to be taken out, blocking others from accessing the needed resource(s).
Name resolution slows down query execution as two probes must be made to resolve to the likely version of the object (that owned by 'dbo'). This is the usual case. The only time a single probe will resolve the name is if the current user owns an object of the specified name and type.
[Edited to further note]
The other possibilities are (in no particular order):
You aren't connected to the database you think you are.
You aren't connected to the SQL Server instance you think you are.
Double check your connect strings and ensure that they explicitly specify the SQL Server instance name and the database name.
In my case I restart Microsoft SQL Sever Management Studio and this works well for me.
If you are running this inside a transaction and a SQL statement before this drops/alters the table you can also get this message.
I eventually shut-down and restarted Microsoft SQL Server Management Studio; and that fixed it for me. But at other times, just starting a new query window was enough.
If you are using variables with the same name as your column, it could be that you forgot the '#' variable marker. In an INSERT statement it will be detected as a column.
Just had the exact same problem. I renamed some aliased columns in a temporary table which is further used by another part of the same code. For some reason, this was not captured by SQL Server Management Studio and it complained about invalid column names.
What I simply did is create a new query, copy paste the SQL code from the old query to this new query and run it again. This seemed to refresh the environment correctly.
In my case I was trying to get the value from wrong ResultSet when querying multiple SQL statements.
In my case it seems the problem was a weird caching problem. The solutions above didn't work.
If your code was working fine and you added a column to one of your tables and it gives the 'invalid column name' error, and the solutions above doesn't work, try this: First run only the section of code for creating that modified table and then run the whole code.
Including this answer because this was the top result for "invalid column name sql" on google and I didn't see this answer here. In my case, I was getting Invalid Column Name, Id1 because I had used the wrong id in my .HasForeignKey statement in my Entity Framework C# code. Once I changed it to match the .HasOne() object's id, the error was gone.
I've gotten this error when running a scalar function using a table value, but the Select statement in my scalar function RETURN clause was missing the "FROM table" portion. :facepalms:
Also happens when you forget to change the ConnectionString and ask a table that has no idea about the changes you're making locally.
I had this problem with a View, but the exact same SQL code worked perfectly as a query. In fact SSMS actually threw up a couple of other problems with the View, that it did not have with the query. I tried refreshing, closing the connection to the server and going back in, and renaming columns - nothing worked. Instead I created the query as a stored procedure, and connected Excel to that rather than the View, and this solved the problem.