I'm not very familiar with MS Access, but a user would like us to create a link to a SQL Server database for him to connect to via MS Access for reporting needs. I tried on my machine, using MS Access 2013, to connect to the database. I tried both options i'm provided with when connecting to an external datasource (ODBC Database). Import the source data as well as link the data source via a linked table.
Both options import the table I want, via a Readonly account our DBA setup, but when I look at the table I noticed that the Primary Key (column name = Id) is missing when viewing in MS Access. Also a bit field we have, which is populated in the SQL Server DB with 0 or 1, in MS Access has rows with -1 instead.
I tried to connect to the database using Sql Server Management Studio, using the Read only account and i'm able to see the primary key as well as the bit field fine.
Any ideas what I might be doing wrong, to be able to see the Primary Key and the bit field properly in MS Access.
The second question you asked about why TRUE is represented as -1 has been asked before. It's the same convention as used in BASIC. TRUE is equal to NOT FALSE. If FALSE is represented with a zero in 16 bits, and if NOT is the bitwise complement, then TRUE is represented by 16 bits set to one.
16 bits set to one, in twos complement notation, is equal to minus one.
What is the datatype of the ID column if it is an Int (Integer) then it should work fine but if not it may be incompatible with Microsoft Access.
The bit column can be set to use a Check Box if you go into the table design Select field and click Lookup Tab in the bottom pane. This setting will not persist if you relink the table however.
Related
My company has a really old Access 2003 .ADP front-end connected to an on-premise SQL Server. I was trying to update the front-end to MS Access 2016, which is what we're transitioning to, but when linking the tables I get all the fields in this specific table as #Deleted. I've looked around and tried to change some of the settings, but I'm really not that into SQL Server to know what I'm doing, hence asking for help.
When converting the table to local, all the info is correctly displayed, so it begs the question. Also, skipping to the last record will reveal the info on that record, or sorting/filtering reveals some of the records, but most of the table stays "#Deleted"...
Since I know you're going to ask: Yes, I need to edit the records.. Although the snapshot method would work for people trying to view the info, some of us need to edit it.
I'm hoping someone can shed some light on this,
Thanks in advance, Rafael.
There are 3 common reasons for this:
You have bit fields in SQL server, but they are null. They should be assigned a default of 0.
The table in question does NOT have a PK (primary key).
Last but not least you need (want) to add a timestamp column. Keep in mind that this is really what we call a “row version” column (so it not a date/time column, but a timestamp column). Adding this column will help access determine if a record been changed, and this is especially the case for any table/form in Access that allows editing of “real” number data types (single, double). If access does not find a timestamp column, then it reverts to a column by column comparison to determine table changes, and due to how computers handle “real” numbers (with rounding), then such comparisons often fail.
So, check for the above 3 issues. You likely should re-run the linked table manager have making any changes.
I can read/write/update the table fine in SSMS, I can open/read/write the table fine if I open the table itself in Access 2013, but if I try to query the table, I get the generic access error message of
ODBC -- call failed
This table has 558,672 rows in it. I have tried using a DSNLess connection with VBA as well as a manually linking the table in through the toolbar in access. What is causing access to throw this error?
EDIT
I have also tried to compact and repair the database to no avail.
EDIT #2
It seems that only one element (a subform) is throwing the ODBC error. The peculiar thing is the main form is based on the same datasource that the sub form is, but only the subform is throwing an error?
I had this problem before here are the thing I had to change to access table with MS Access and edit it.
1.your tables should have a primary key. In the column properties, set identity specification to yes, and Identity increment by 1. I would prefer to set a completely new column with int data type.
2. No null values in boolean fields everything should be 1 or 0. and set a constraint to 0.
I'm doing it programmatically (I'm a newbie to sql) I'm getting the data per table within first DB using with being a value from a list of table names that I need to make sure are
there
if there have the corresponding values in the same table in
DB X list all the fields that do not have the same values and the
value in below
Table that does match listing the table, field name, row,
"SELECT * FROM [Dev.Chris21].[dbo].[" & PayrollTablemaskedarray(xxxxxx-2) & "]"
I can copy the whole thing into excel but I'm wondering is there a way to do this using sql?
Thanks
Since you mention that you're doing it programmically I assume you're using visual studio. If so you can take advantage of SQL Server Data Tools (SSDT) to do comparisons of two database schemas or two database data sets. You get this out of the box with VS2012 or VS2013 (and earlier versions too). Might be worth a look...
When you use default value for a column in SQL Server Management Studio table designer, SSMS change your default and stand Parenthesis around of that (In all editions and all versions of SQL Server). For example if you set 0 as default value, this default changed to (0). I don't know why sql server use parenthesis, and is there a practical reason.
Thanks in advance.
There are certain types of objects, such as DEFAULTs and CHECK constraints that SQL Server doesn't store the original, textual form of - in contrast with, say, stored procedures, where you can (absent encryption) always retrieve it in the exact form you gave it to the server - complete with any white space, formatting, comments, etc.
Because SQL Server doesn't store the textual form, it always has to re-generate textual forms to show to users when they ask for such objects. When and where it chooses to insert parentheses can be a bit of a mystery (it's not documented) but since they don't change the meaning of the expression, they shouldn't be a concern.
Actually, 0 and (0) will evaluate to the same result, so there is nothing to really overcome. Ignore it. It's just how SQL stores them internally and a visibility issue.
It does that is you do it interactively as well. Not sure why does this , but not to worry.
I have table [user], created in SQL Server Management Studio, with this structure:
id int PRIMARY NOT NULL
login varchar(255) NOT NULL
password varchar(32) NOT NULL
Now, I want to insert first user into database. Right click to table [user], choose Edit top 200 rows and type new user values into the grid:
id | login | password
1 | admin | MD5('admin')
But after save, inserted password is MD5('admin'), but I expect the 21232f297a57a5a743894a0e4a801fc3 hash.
How can I do that in Microsoft SQL Server Management Studio?
Thanks
P.S. I am using SQL Server 2008 Express 10.50.1600.1 and Microsoft SQL Server Management Studio 10.50.1600.1.
hash values are byte arrays, not character strings. Use VARBINARY column type.
Do not insert MD5 of unsalted passwords. It takes 2.96 seconds to reverse crack online the hash to the password. Use a properly salted password and write the salt in the table.
Right click to table [user], choose Edit top 200 rows and type new user values into the grid. Well, what do you expect? The table edit is a feature to enter values, and if you enter the string MD5('admin') then the value in the table will be... MD5('admin'). It is not an interactive function evaluator (aside from MD5 not being a SQL Server function...)
Do not reinvent the wheel, specially do not reinvent a security wheel if you don't speak fluent crypto. Most frameworks have modules for membership management. Eg. Introduction to Membership.
You cannot run queries in grid tables, you have to run query to do update. To calculate MD5 you can use:
CONVERT(VARCHAR(32), HashBytes('MD5', 'admin'), 2)
The Edit Top 200 Rows feature is for interactive data entry, where only values are accepted, not expressions that need to be evaluated before being stored.
If you want the actual value inserted to be the result of an expression, use a query window to insert the data. (I don't know if you used the Edit feature merely because you wanted to try that functionality or for some other reason, but if that was because you didn't know how to insert data using SQL, take a look at this manual.)
Also, as #Damien has correctly noted, there's no MD5 function in Transact-SQL. There is one called HASHBYTES, which can use various hashing algorithms, including MD5. But the result of this function is varbinary, not varchar. For MD5 specifically, it is varbinary(16). To store the direct result of HASHBYTES, therefore, you'll need to change the type of the password column accordingly.
So, change the type of the column, then open a new query window and type in a command (or statement) to insert the data. The one that should do the job for you might look something like this:
INSERT INTO user (id, login, password)
VALUES (1, 'admin', HASHBYTES('MD5', 'admin'));
To be fair, you may omit changing the column type, in which case you'll need to replace the simple HASHBYTES call like above with one like in #Garath's answer. Whether you really need to store the hashes as varchar(32) instead of varbinary(16) is an entirely different question, though.