On 2015-08-13 10:26 AM, Chris Parsonson wrote: > OK here's my code which is just test code, not intended to do anything > useful. It runs without error, but the DELETE just doesn't do anything > Dim dbConnection As New SQLiteConnection > Dim dbDataSet As New DataSet > Dim SQLStmt As String > Dim sDBPath As String = Application.StartupPath & "\wolfpro.db3" > Dim sUpdateDBPath As String = Application.StartupPath & > "\UpdateWolfpro.db3" > Try > If dbConnection.State = ConnectionState.Closed Then > dbConnection.ConnectionString = "Data Source=" & sDBPath & > ";New=True;Compress=True;Synchronous=Off" > dbDataSet.Locale = CultureInfo.InvariantCulture > dbConnection.Open() > dbDataSet.Reset() > End If > SQLStmt = "ATTACH '" & sUpdateDBPath & "' AS UPD;" > Dim dbcommand As SQLiteCommand = dbConnection.CreateCommand > With dbcommand > .CommandText = SQLStmt > .ExecuteNonQuery() > .Dispose() > End With > SQLStmt = "DELETE FROM UPD.Items;" > Dim dbcommand2 As SQLiteCommand = dbConnection.CreateCommand > With dbcommand2 > .CommandText = SQLStmt > .ExecuteNonQuery() > .Dispose() > End With > Return True > Catch ex As Exception > MessageBox.Show(ex.Message) > Return False > End Try
Afraid I'm not too familiar with VB, but from the looks of it I see a first problem seeming like you attach a database that sits in your application startup path... this won't work on any newer Windows if the user has UAC turned on since it doesn't allow anyone/anything to mess with files in the App folder (typically c:\ProgramFiles\ or c:\ProgramFiles (X86)\). The UAC will typically virtualize that folder into your AppPath somewhere, just search for that DB file in subfolders of "c:\Users\(your User)\AppData\" to see where it ended up. To verify this is not the problem, simply put that UpdateWolfpro DB in the Documents folder or AppData folder and adjust the code to suit. The correct place to put data files in Windows will be in the "c:\Users\(username)\AppData\Roaming\(YourAppName)\" (more or less) but that is another discussion. Let us know if that works. > > > On 13 August 2015 at 10:12, R.Smith <rsmith at rsweb.co.za> wrote: > >> To Attach a second Database is fairly straightforward and shouldn't fail >> unless there is a physical problem with either of the files. >> >> The Attach command example is like this (on a WinX machine): >> >> ATTACH DATABASE 'C:\Documents\OtherDatabase.db' AS "DB2"; >> >> Execute that as a standard SQL statement. If that file does not exist, it >> will be created - but the path needs to be valid. >> If that statement does not work for you, please let us know what the error >> message is. >> >> Once the statement did work, the second database can be accessed by >> prepending any reference with "DB2", so assuming you have a table in the >> current database called "MyTable" that needs to add rows that doesn't exist >> yet in the same named (with the same schema) table in the attached database >> on a Primary key called "RecID", this SQL might work: >> >> INSERT INTO DB2.MyTable SELECT * FROM MyTable WHERE MyTable.RecID NOT >> IN (SELECT RecID FROM DB2.MyTable); >> >> More information here: >> http://www.sqlite.org/lang_attach.html >> >> On 2015-08-13 07:13 AM, Chris Parsonson wrote: >> >>> Now we get down to the first real problem that of the ATTACH. I have never >>> been able to get that to work. If I could have got the ATTACH to work I >>> probably would never have had to ask the synchronisation question. >>> Although >>> I have never had to do it before in SQLite, I have worked a lot with SQL >>> Server doing synchronisation there >>> >> >> >> >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users at mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> > >
