I've done some searching and can't seem to find an answer anywhere.
What can happen (if anything) if an entry in an SQL DB contains actual SQL code?
I've just found that an internal application at work (SQL based) can insert anything into a table including code. The datatype of the columns with this ability is Varchar.
Is there any risk with this ability, and what/how can this be a bad thing?
Related
Whether in a script window or in a stored procedure, is there any way to get SQL Server Management Studio to follow the current target a synonym points to so that syntax checking works? I'm writing SQL statements that reference a synonym that may, at different times, point to a table in one or another instance (dev, test, etc.) of the same database. It would be really nice if I didn't have red squiggles under all of the column names belonging to the underlying table when I know they're correct! Is there any way to get SSMS to figure out that they're correct?
I've a MS Access solution accessing to linked tables to SQL Server.
Today it happens that one key filed in a table reached the limit of int.
So my first idea was to change it from int -> bigint but it seems to be not possible as ALTER queries return a couple of errors for.
The second idea was to clone the key field, delete original and make the clone to the new key field.
This worked without problems but now the linked table only show #deleted values for all fields within the table.
It seems that MS Access uses the keys for some relations when it access to the backend.
Maybe somebody know a solution to extend /reset the key without loosing the relation for MS Access?
Thank you
MsAccess has a "long integer" number option in the table design, which has the same size of INT from SQL Server. See below:
https://www.microsoft.com/en-us/microsoft-365/blog/2017/03/06/new-in-access-2016-large-number-bigint-support/
I found this:
"Unfortunately, Access is unable to use BigInt as a primary key. You will most likely need to change this to a long integer. The article below is for an older version of Access, but the info still applies:" (https://answers.microsoft.com/en-us/msoffice/forum/all/linked-table-showing-deleted-in-all-rows-and/d0451a78-08c1-4667-8677-6c61edcebcf1)
So it seems not to be possible to use bigint as key.
I Googled this topic, and this is what I found...
Access CAN handle the BigInt datatype in SQL Server. Only, its handling of this is somewhat faulty.
As far as Access is concerned, BigInt is a STRING. You have to quote it as a string, within Access. Fortunately this isn't a problem on the SQL Server end, as SQL Server is happy with quoted numbers. In-between the two (Access and SQL Server), based on my experience, it appears there is a textual transmission of SQL commands from Access to SQL Server, with some modest dialect translation going on automatically in the background (if anyone knows better, please comment.) BigInt data coming from SQL Server to Access are automatically understood as strings.
https://social.msdn.microsoft.com/Forums/office/en-US/fb6f99ec-2ed7-487b-ba39-0777a0b44d5f/the-bigint-problem?forum=accessdev
MS Access is a 30 year old technology. Do you really want to be using that in 2022 and in the future?
I'm trying to import data into SQL Server using SQL Server Management Studio and I keep getting the "output column... failed because truncation occurred" error. This is because I'm letting the Studio autodetect the field length which it isn't very good at.
I know I can go back and extend the column length but I'm thinking there must be a better way to get it right first time without having to manaully work out how long each column is.
I know that this must be a common issue but my Google searches aren't coming up with anything as I'm more looking for a technique rather than a specific issue.
One approach you may take, assuming the import is not something which would take hours to complete, is to just set every text column to VARCHAR(MAX), and then complete the CSV import. Once you have the actual table in SQL Server, you can inspect each column using LEN to see how wide it is. Based on that, you can either alter columns, or you could just take notes, drop the table, and reimport using appropriate widths.
You should look into leveraging SSIS for this task. There is somewhat of a fixed cost in terms of spending time setting up the process for importing the csv file and creating a physical table in the database. Ultimately, though, you will be able to set the data types for each column/field in your file. Further, SSIS will enable you to transform or reformat the data to say the least.
I would suggest downloading Visual Studio and SQL Server Data Tools. The latter contains the necessary tools, including SSIS, SSRS, and SSAS, for which you would need to complete this task.
The main point is being able to automate this task, especially if it's an ongoing project of uploading csv files into the database.
I need to transfer certain information out of our SQL Server database into an MS Access database. I've already got the access table structure setup. I'm looking for a pure sql solution; something I could run straight from ssms and not have to code anything in c# or vb.
I know this is possible if I were to setup an odbc datasource first. I'm wondering if this is possible to do without the odbc datasource?
If you want a 'pure' SQL solution, my proposal would be to connect from your SQL server to your Access database making use of OPENDATASOURCE.
You can then write your INSERT instructions using T-SQL. It will look like:
INSERT INTO OPENDATASOURCE('Microsoft.Jet.OLEDB.4.0','Data Source=myDatabaseName.mdb')...[myTableName] (insert instructions here)
The complexity of your INSERTs will depend on the differences between SQL and ACCESS databases. If tables and fields have the same names, it will be very easy. If models are different, you might have to build specific queries in order to 'shape' your data, before being able to insert it into your MS-Access tables and fields. But even if it gets complex, it can be treated through 'pure SQL'.
Consider setting up your Access db as a linked server in SQL Server. I found instructions and posted them in an answer to another SO question. I haven't tried them myself, so don't know what challenges you may encounter.
But if you can link the Access db, I think you may then be able to execute an insert statement from within SQL Server to add your selected SQL Server data to the Access table.
Here's a nice solution for ur question
http://www.codeproject.com/Articles/13128/Exporting-Data-from-SQL-to-Access-in-Mdb-File
There is a hard limit of the number of parameters any single SQL statement can have, and that is 2100 (for SQL Server 2005), or 1024 (for SQL Server 2000).
Does anyone know of a way to increase that number?
If you'd like to know "why" (as I would be dying of curiosity myself), the ansewr is in this:
MyL2SDataContext.Accounts.Where(acct=> selectedAccountIDs.Contains(acct.ID))...
Thanks,
It's a hard limit - and I would seriously think about rethinking a real need to extend that, especially in light of the example code you give.
There is no way to increase that number. You could put the values you need in another table (or tables), insert the records into that table, with a key, and then pass that key to the stored procedure.
I'm aiming for a more long term and permanent solution to this using xml. For SQL Server 2005 and above an xml type could probably be used to bring over a local collection in Linq to SQL as a single parameter and maybe OpenXml could be used for SQL Server 2000.
As far as being able to increase that limit, I'm not sure and that's how I actually ended up at this post. I'll post back anything I find here though after my research.
See my post on the Microsoft Connect site and vote if you would also like to see this fixed.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=475984