I need all your helps asap!!!

[koolj]

Hi all!!!
i am getting trouble with Flash Remoting with .NET when implementing my web-base app...
And i really really need your helps to my situation:
I use Flash MX 2004 v7.02 and Flash Remoting Component 2004, and i use .NET asembly method.
Here is my configuration on my PC (they are imgs and you can view it):

The dll files



The Database & other files


The C#codepage


The AS codepage with functions get & call services.


The .NET compiler while compiling the C# codepage without bugs


The NetDebugger satus after i generated the FlA file. you can see the function "InsertData" could nor run correctly


And the detail of this bug.


Here the Manipulating Data from Mook's Book that i refered. But it came these bugs


I use database MS Access.
The problem comes when the function "InsertData" that contained INSERT SQl query did not run.
and NetDebugg come a bug "Operation must use a upateable query"
And my question is "Why did it comes that bug" ?
If one of you used to get the same problem. pls guide me!!

Big thanks to all ya for reading me!!!

[cybertrance]

This might help a little:
-------------------------------------------------------------------------
CAUSE
This article explains the four primary causes of this error and the corresponding workarounds. Although this article refers to Microsoft Access databases, the information provided here also applies to other types of databases.



RESOLUTION
This error is typically encountered when your script attempts to perform an UPDATE or some other action that alters the information in the database. This error occurs because ADO is unable to write to the database for one of the following reasons:



The most common reason is that the Internet Guest account (IUSR_MACHINE), which is by default part of the "Everyone" group, does not have Write permissions on the database file (.mdb). To fix this problem, use the Security tab in Explorer to adjust the properties for this file so that the Internet Guest account has the correct permissions.

NOTE: When using Microsoft Access databases with ADO, it is also necessary to give the Internet Guest account Write permissions on the directory containing the .mdb file. This is because Jet creates an .ldb file to handle database locking. You may also need to give read/write permission on the "Temp" folder because Jet may create temporary files in this directory.


A second cause of this error is that the database was not opened with the correct MODE for writing. If you perform the Open on the Connection object, you use the Mode property to indicate the permissions on the connection as shown here:

SQL = "UPDATE Products Set UnitPrice = 2;"
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Mode = 3 '3 = adModeReadWrite
Conn.Open "myDSN"
Conn.Execute(SQL)
Conn.Close

NOTE: By default, the MODE is set to 0(adModeUnknown), which generally allows updates.


Another cause of this error is that the "Read Only" setting may be checked in the Options page for this DSN in the ODBC Manager.


The last issue and work around pertains to any SQL data source. The error can be caused by SQL statements that violate referential integrity of the database. Here are a few of the most common queries that fail:



The simplest group to deal with are those you cannot change: crosstab, SQL pass-through, union, or update (or make-table) action queries that have UniqueValue properties set to Yes.


Another very common cause is when the join includes linked ODBC tables that do not have unique indexes. In this case, there is no way for SQL to guarantee that records are unique in a table that has fields whose value will change with the query.


One cause does have a robust workaround. If you try to update a join field on the "one" side of a "one-to-many" query it will fail unless you turn on cascading updates. This way, you delegate referential integrity to the JET engine.
-----------------------------------------------------------------------

[koolj]

Zitat von cybertrance

This might help a little:
-------------------------------------------------------------------------
CAUSE
This article explains the four primary causes of this error and the corresponding workarounds. Although this article refers to Microsoft Access databases, the information provided here also applies to other types of databases.



RESOLUTION
This error is typically encountered when your script attempts to perform an UPDATE or some other action that alters the information in the database. This error occurs because ADO is unable to write to the database for one of the following reasons:



The most common reason is that the Internet Guest account (IUSR_MACHINE), which is by default part of the "Everyone" group, does not have Write permissions on the database file (.mdb). To fix this problem, use the Security tab in Explorer to adjust the properties for this file so that the Internet Guest account has the correct permissions.

NOTE: When using Microsoft Access databases with ADO, it is also necessary to give the Internet Guest account Write permissions on the directory containing the .mdb file. This is because Jet creates an .ldb file to handle database locking. You may also need to give read/write permission on the "Temp" folder because Jet may create temporary files in this directory.


A second cause of this error is that the database was not opened with the correct MODE for writing. If you perform the Open on the Connection object, you use the Mode property to indicate the permissions on the connection as shown here:

SQL = "UPDATE Products Set UnitPrice = 2;"
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Mode = 3 '3 = adModeReadWrite
Conn.Open "myDSN"
Conn.Execute(SQL)
Conn.Close

NOTE: By default, the MODE is set to 0(adModeUnknown), which generally allows updates.


Another cause of this error is that the "Read Only" setting may be checked in the Options page for this DSN in the ODBC Manager.


The last issue and work around pertains to any SQL data source. The error can be caused by SQL statements that violate referential integrity of the database. Here are a few of the most common queries that fail:



The simplest group to deal with are those you cannot change: crosstab, SQL pass-through, union, or update (or make-table) action queries that have UniqueValue properties set to Yes.


Another very common cause is when the join includes linked ODBC tables that do not have unique indexes. In this case, there is no way for SQL to guarantee that records are unique in a table that has fields whose value will change with the query.


One cause does have a robust workaround. If you try to update a join field on the "one" side of a "one-to-many" query it will fail unless you turn on cascading updates. This way, you delegate referential integrity to the JET engine.
-----------------------------------------------------------------------

Thank u thank u cybertrance!!!
I just applied the solution of the first cause! and it run well!!!
Big thanks u!!!