i'm using vb 2008 and local database sql server compact 3.5 to build a application.
the problem is that i can't insert a new data to the database from the app. i'm wrote the query right at dataset and using table adapter. but when i call the query, it succeed but the data don't exist at database.
for example:
at table adapter, i made AddData() like:
INSERT INTO supplier (kode_supp, name)
VALUES (#p1,#p2)
so at the app, i actually can call them by write: frmSupplier.tableadapter.AddData()
but it's not working, do i miss something to connect the db?
help me..
EDIT:
how can i call a commit or update method then?
and yes, i use datagrid to show db data.
when i run the app, all data in db is showed.
it means that the db and app is connected right?
but why when i add data, it's not working. actually when i run it, it says that adding process is success, no error, and it shows at the datagrid.
but when i look at database. the data that i add is not there.
and in tableadapter, i also make sortData, seachData query, i can use both of them perfectly when i run the app.
so, i really confuse why is the insert query didn't work.
did i miss something to connect the sqlserver compact 3.5 with vb 2008? but some of them works.
You may need to call a commit or update method in order to do this. Not forgetting that when working with data in an app there are often times when you are essentially disconnected from the database and modifications you perform in an app - in memory - may well be some modified view of the "actual" underlying data in the database.
Would be better to show up more codes as it is more clear on the process. First of all, how do you execute the query? Second, how do you pass the value into AddData() function?
look at the following URL may give you some ideas
http://support.microsoft.com/kb/308055
Related
I have created a data entry application that works like this. All data entered goes in to an ACCESS table. At any time the user can hit the update button and the new data in the ACCESS table updates a table in a SQL Server data base. Recently, we have a need for multiple people to be doing data entry at the same time, and I am a bit confused about what is happening with the ACCESS table. I conducted experiments with two users updating the access table then closing the app before updating and after updating. My question is this: everything seems to work fine, no data is missing from either the ACCESS table or the SQL Server table. This begs the question of where does the ACCESS table reside when two versions of the app are open at the same time. Are there two versions of the ACCESS table or just one version that is used by both applications. I think it's the latter but I am not sure, because when we hit the update button on one users pc the data from both users is updated. I am trying to decide if I need to put the ACCES table up on SQL SERVER as well but would like to avoid the extra work.
Thanks
JPL
How can I link query from another MS Access database? I know I can easily link tables, But I don't know how to link queries. The query takes data from many tables which I don't want to link.
You can do it this way:
SELECT [RemoteQueryname].* FROM [RemoteQueryname] IN 'C:\RemoteDatabase.mdb'
I have tested with databases locally on my machine and runs flawlessly. The only note I would like to point out is before running the query check to make sure the remote databse is closed or it will crash the one trying to do the query.
The "official" way, by which I assume you mean using the buttons on the ribbon, TMS, would be to use a Make Table Query. Of course, to update the linked data, you would have to run the make table query every time.
We're trying to pinpoint the source of some unexpected updates happening on a SQL Server table. What I'd like to do is create a trigger on that table monitoring that column we're interested in, and when updates occur, write some audit info into a separate table.
Works great and fine for things like user name, date, old and new columns values (from the Inserted and Deleted trigger tables) - but I'd like more :-)
In SQL Profiler, you can see the name of the app that's connected to SQL Server in the profiles - the part that can be defined in the connection string as Application Name:
Data Source=(local);Initial Catalog=AdventureWorks;
Integrated Security=True;Application Name="My Application"
Is there any way in a T-SQL FOR UPDATE trigger to get at this information?
SELECT APP_NAME()
Marc_S the sP_whoIsActive stored Procedure probably will solve Your problems
as posted here
and it's awesome part of T-SQL by the way
Not sure but could you possibly log the server name if you applications are on multiple servers? It might help narrow down the list of applications.
Is there any handy tool that can make updating tables easier? Usually I got an Excel file with the original value in one column and new value in another column. Then I write a formula in Excel to create the 'update' statement. Is there any way to simplify the updating task?
I believe the approach in SQL server 2000 and 2005 would be different, so could we discuss them both? Thanks.
In addition, these updates usually request by "non-programmer" (which means they don't understand SQL, so it may not feasible to let them do query), is there any tool that can let them update the table directly without having DBAs do this task? Also, that tool needs to limit the privilege to only modify certain tables. And better has a way rollback the change.
Create a DTS package that will import a csv file, make the updates and then archives the file. The user can drop the file in a specific folder designated for the task or this can be done by an ops person. Schedule the DTS to run every hour, day, etc.
In case your users would insist that they keep using Excel, you've got several different possibilities of getting the data transferred to SQL Server. My preferred one would be to use DTS/SSIS, as mentioned by buckbova.
However, another method is by using OPENROWSET(), which makes it possible to query your Excel file as if it was a table. I wrote a small article about it here: http://blog.hoegaerden.be/2010/03/29/retrieving-data-from-excel/
Another approach that hasn't been mentioned yet (I'm not a big fan of letting regular users edit data directly in the DB), any possibility of creating a small custom application for them?
There you go, a couple more possible solutions :-)
Valentino.
I think the best approach is to expose a view on your data accessible to users who are allowed to do updates, and set up triggers on the view to perform the actual updates on the underlying data. Restrict change to only the columns they should be changing.
This technique can work on SQL Server 2000 and 2005.
I would add audit triggers on the underlying tables so you can always track changes.
You'll have complete control, and they can connect to it with Access or whatever and perform their maintenance.
You could create some accounts in SQL Server for these users and limit their access to only certain tables and columns along with onlu select / update / insert privileges. Then you could create an access database with linked tables to these.
As we do not implement the users of our applications as users in SQL server, when the application server connects to a database each application always uses the same credentials to attach to each database.
This presents an auditing problem. Using triggers, we want to store every update, insert and delete and attribute each to a particular user. One possible solution is to add an "updated by user" column to every table and update this every time. This means a new column on every table and a new parameter on every stored procedure. It also means you can only do soft deletes.
Instead of this I propose using the Application Name property of the connection string and reading this with the App_Name() property inside the trigger. I tested this with a simple app and it seems to work (the format could be as so: App=MyApp|User=100).
The question for you guys is, is this a bad idea and do you have a better one?
I use SET CONTEXT_INFO for this. It's just what you need.
It certainly seems like a feasible solution, although you'll need to inject the username into the connection string each time your application loads. Note that this solution probably wouldn't work with a web application, as your connection string will be different each time, which could lead to huge connection pooling issues.
Another option is to retrieve the hostname/IP address (SELECT host_name() ) and store that instead.
You wouldn't necessarily need a new parameter on each stored procedure, as you can modify each stored procedure (or the trigger) to automatically insert the App_Name/Hostname.
A potential drawback is that any modifications performed via Management Studio won't have the custom App_Name, and you'll be left with "Microsoft Management Studio" as the user.
We use the Application Name property to control auditing triggers and have not seen any problems using it, and haven't noticed any speed issues (though in our case, we're specifically not auditing for certain applications, so its hard to measure how much time not doing something takes :))