Page 1 of 1

Problems with grid

PostPosted: Fri Nov 01, 2013 12:32 am
by fieldhopper
Hey,
my programm use mysql-tables and the programm runs in a network, was used by 40 users. When a user works with a special table to change or add datas, a very strange thing happend. The user add a new sentence and fill it with datas. After saving the sentence it will be sometimes override with datas from the following or before sentence. The input was gone. Scrolling very quickly have the result that some sentence are overridden with the marked row.
The tables are always the same which have this appearance. What can i do. Have someone an idea to stop this appearance.
THX Bernd

Re: Problems with grid

PostPosted: Fri Nov 01, 2013 10:09 am
by Neosoft Support
You may need to use a server-side cursor to properly lock the records and prevent users from overwriting each other's work.

From the DBPro help file:

By default NeoBookDBPro uses something called a client-side cursor. Simply put, this is a method of accessing data that relies on the client application to handle most of the data storage and processing. Client-side processing is very flexible and generally provides the fastest performance for small to medium sized databases. For large databases, however, a client-side cursor can sometimes consume too many system resources resulting in poor performance. To compensate for this problem, you may want to use a server-side cursor when working with very large databases. In NeoBookDBPro you can switch to a server-side cursor by adding "CursorLocation=Server" to your connection string. For example:

dbpOpenDatabase "MyDB" "Provider=MSDASQL.1;Driver={MySQL ODBC 3.51 Driver};Server=localhost;Database=test;User=root;Password=apple;Option=3;CursorLocation=Server"

With a client-side cursor (the default) all data is copied to the local machine and processed there. This provides access to features not normally supported by servers such as sorting and indexing. When using a SQL query, only the data returned is copied to the local machine. A server-side cursor doesn't provide as much flexibility, but is often more appropriate for large databases, and may be required when the size of a database exceeds the available memory and disk space available on a local machine.

Re: Problems with grid

PostPosted: Tue Nov 05, 2013 2:17 am
by fieldhopper
I have tried and the program-info was:

dbpError=Der ODBC-Treiber unterst├╝tzt die angeforderten Eigenschaften nicht

dbpError=The ODBC driver does not support the requested properties

Here the command in program:

dbpOpenDatabase "LEP" "Provider=MSDASQL.1;Driver={MySQL ODBC 3.51 Driver};Server=localhost;Database=schulsystem;CursorLocation=Server;User=root;Password=;Option=3"

What is wrong :( and what can i do :wink: ?

Re: Problems with grid

PostPosted: Tue Nov 05, 2013 11:50 am
by Neosoft Support
dbpError=The ODBC driver does not support the requested properties


That error originates from the driver, which seems to indicate that it does not support that feature which I think is necessary to properly handle multi-user access. I'm not sure what else to suggest except maybe trying a newer version of the ODBC driver. I think they are up to v5 now.

Re: Problems with grid

PostPosted: Fri Nov 15, 2013 1:05 am
by fieldhopper
Hey,

i've tried the driver 3.51 and 5.2 (the newest which i found). Her the result of both driver:
dbpOpenDatabase "LEP" "Provider=MSDASQL.1;Driver={MySQL ODBC 3.51 Driver};Server=localhost;Database=schulsystem;CursorLocation=Server;User=root;Password=;Option=3"
returns with no error in the debugger.
dbpopen on a table returns with no error, so it seems.
The Reccount of the table shows -1 , no records, but the table contains many records. which were shown when i work without the Cursolocation.
Is there any way to use the database-instructions in a right way ? I need it so urgently. May be a workaround.

Re: Problems with grid

PostPosted: Fri Nov 15, 2013 4:47 am
by Gaev
Fieldhopper:
The Reccount of the table shows -1 , no records, but the table contains many records. which were shown when i work without the Cursolocation.
I believe that is how CursorLocation=Server is supposed to work ... as Dave said ...
When using a SQL query, only the data returned is copied to the local machine.
... no records are sent to your machine until you ask for them ... so if you have a million records in a database in a far far location, it does not try and fetch all of them when you dbpOpenTable.
Is there any way to use the database-instructions in a right way ?
I haven't tried this option myself ... but you might try and issue a dbpQuery command ... or the generic dbpExecSQL ... to fetch the records that you need to work on ... then perhaps [ID.Table.$RecCount] will reflect the number of matching records delivered to your machine.

Re: Problems with grid

PostPosted: Mon Nov 18, 2013 12:05 pm
by Neosoft Support
Also, make sure all of your tables include a unique primary key field. Many databases rely on the primary key for many tasks. You may be able to solve this problem by making one of your fields a primary key. This is a quirk of client-server databases. The easiest way to do this is to use an AutoInc type field which will always be unique. You can add a new primary key field to an existing database using the action below:

dbpExecSQL "id" "ALTER table tablename ADD ID COUNTER;ALTER table tablename ADD PRIMARY KEY (ID)" ""

With the primary key properly defined, you can try removing the CursorLocation=Server option.

Re: Problems with grid

PostPosted: Thu Nov 28, 2013 2:49 am
by fieldhopper
Hey,
i have new results. First i have to explain that i use in each table a primary-key-field. It was a long search to find out that the dbpPrintreport or dbpPreviewreport is the culprit. Without starting the report everything happend well. Start the report between the commands, the error happend. Only starting the reports in a new neoprogramm with run the result was good.
Maybe the Report have a bug.

The next funny error is :

A report which is create have alwas the same look when it was printed. Only one computer in the net never reacts on changing the report. My suspicion is that the computer is the guilty on or maybe it can be the report ?

Re: Problems with grid

PostPosted: Thu Nov 28, 2013 12:32 pm
by Neosoft Support
I'm not sure why generating a report would cause problems, but that's an interesting observation. The report does open a new connection to the database, but it should just read the data not make any changes. I will do some research and see if there might be something in the report module that can be changed to address this problem.

Re: Problems with grid

PostPosted: Thu Nov 28, 2013 1:08 pm
by fieldhopper
After a new connection the report doesn't change the record. It change it when i use the report in my code. I hope i explain it correctly and you search on the right way :-).

Re: Problems with grid

PostPosted: Mon Dec 02, 2013 11:35 am
by Neosoft Support
Try calling dbpSaveEdits before generating the report.

If that doesn't help, can you supply us with the code you use to generate the report. This will help us reproduce the problem.

Re: Problems with grid

PostPosted: Wed Dec 04, 2013 12:25 am
by fieldhopper
The whole code. It is a very complex programm and i think you need dates to control the system, but there is no problem the send the pub.
By the way, i have test the dbpSaveEdits, but does not help.

Re: Problems with grid

PostPosted: Wed Dec 04, 2013 11:51 am
by Neosoft Support
You can send the pub to: info <at> neosoftware.com

Also, please include a list of steps required to reproduce the problem.