Search found 13 matches

by trygvelo
Fri 03 Jul 2009 08:04
Forum: dotConnect for MySQL
Topic: Zerofill columns
Replies: 1
Views: 1803

Zerofill columns

Hi,

I've got several fields where I need to save fixed length numeric only data. I followed the mysql recommendation and created these fields as f.ex int(4) unsigned zerofill for a 4 digit numeric field. I tried filling a typed dataset table with this column with a value of 0012 in db. The value when using datatable column type to System.int32 leaves a 12 in the dataset, if setting dataset column type to System.String it still gives me a value of 12, not 0012 as I would expect.

I had to revert to using char(4) in the database for this to work. What is the reason the int(4) unsigned zerofill doesn't work when reading it from db to a datatable in a typed dataset? Is it dotConnect or the DataSet design that is to blame?
by trygvelo
Wed 27 May 2009 10:24
Forum: dotConnect for MySQL
Topic: Lost Connection to MySQL server during query
Replies: 5
Views: 3660

A restart of MySQL temporarily fixes the issue. It will resurface after 8-24 hours. There must be some issues with the connections in CoreLab connection pool.

How do I best close the connections of a TableAdapter (TableAdapter IN dataset, not a standalone DataAdaptor) or will the TableAdapter connection be closed automatically after it has been used?

I'm currently doing this:

Code: Select all

DATASETS.dsStatusLogicTableAdapters.statuslogicTableAdapter daSL = new DATASETS.dsStatusLogicTableAdapters.statuslogicTableAdapter();
try
{
    daSL.Fill(dsSL.statuslogic);
}
finally
{
    daSL.Connection.Close();
}
using (daSL.Connection)
{
    daSL.Fill(dsSL.statuslogic);
}

Can I use the "using" statement instead on either the TableAdapter.Connection OR on the TableAdapter object itself?

Code: Select all

DATASETS.dsStatusLogicTableAdapters.statuslogicTableAdapter daSL = new DATASETS.dsStatusLogicTableAdapters.statuslogicTableAdapter();

using (daSL.Connection)
{
    daSL.Fill(dsSL.statuslogic);
}
OR

Code: Select all

using (DATASETS.dsStatusLogicTableAdapters.statuslogicTableAdapter daSL = new DATASETS.dsStatusLogicTableAdapters.statuslogicTableAdapter())
{
    daSL.Fill(dsSL.statuslogic);
}
by trygvelo
Wed 27 May 2009 07:48
Forum: dotConnect for MySQL
Topic: Lost Connection to MySQL server during query
Replies: 5
Views: 3660

Same problem here. It is not easy to reproduce because it works fine for a while, then this starts happening after a lot of requests towards the database. The same query works fine in MySQL Query Browser. I have used a .net typed dataset with a TableAdapter and let the CoreLab generated dataset code handle all the query execution, opening/closing of connections etc. The query returns ~16000 rows in 0.3 secs from a single table.

It used to work fine when I had a DataAdapter in my component code and called the Fill method "manually". That's the only change from the last version of the affected software.

I'm currently using CoreLab 4.70, should have upgraded to cure another bug, but I'm afraid to do it since I'll probably run into new bugs with a new version. At least that's been the case every time I've upgraded in the past.

Same stacktrace as thread starter too:

CoreLab.MySql.MySqlException: Lost connection to MySQL server during query
at CoreLab.MySql.a9.a(Byte[] A_0, Int32 A_1, Int32 A_2)
at CoreLab.MySql.a9.a()
at CoreLab.MySql.a9.b(Byte[] A_0)
at CoreLab.MySql.c.a(Byte[] A_0)
at CoreLab.MySql.c.a(Byte[] A_0, Boolean A_1)
at CoreLab.MySql.bi.f()
at CoreLab.MySql.z.b(Boolean A_0)
at CoreLab.MySql.MySqlDataReader.a(Boolean A_0)
at CoreLab.MySql.MySqlDataReader.Close()
at CoreLab.Common.DbDataTable.l()
at CoreLab.Common.DbDataTable.i()
at CoreLab.Common.DbDataTable.CancelFetch()
at CoreLab.Common.DbDataTable.a(Int32 A_0, Boolean A_1)
at CoreLab.Common.DbDataTable.b(Boolean A_0)
at CoreLab.Common.DbDataTable.Fill()
at CoreLab.Common.DbDataTable.Fill(Object[] parameterValues)
at ProTeria.DB.AESHandler.getAES_CodelistsNew(String countrycode)
by trygvelo
Tue 09 Dec 2008 14:48
Forum: dotConnect for MySQL
Topic: BUG? Setting MySqlCommand.CommandText in DataAdapter
Replies: 7
Views: 3059

Done, attachment is 3.9MB zip file, sending from gmail account, hope it doesn't get blocked by your spam filter.
by trygvelo
Tue 09 Dec 2008 08:42
Forum: dotConnect for MySQL
Topic: BUG? Setting MySqlCommand.CommandText in DataAdapter
Replies: 7
Views: 3059

Any progress with this issue? I sent you the test project about a month ago.
by trygvelo
Mon 27 Oct 2008 10:21
Forum: dotConnect for MySQL
Topic: BUG? Setting MySqlCommand.CommandText in DataAdapter
Replies: 7
Views: 3059

BUG? Setting MySqlCommand.CommandText in DataAdapter

App first developed with version 3.50.14. Recently upgraded to 4.85.35.

Error:
Runtime exception randomly occurs when setting SelectCommand.CommandText. It occurs seldom and the same code is run a lot of times each day, called from different contexts (Windows service app and WebService app).

Code that fails:
this.selComAES.CommandText = resources.GetString("selComAES.CommandText");


Background:
I have one DB classlibrary project. One class is AESHandler, it has several CoreLab.MySql.MySqlDataAdapter's, one of them is daAES. It is used to fill a DataSet with data together with several other DataAdapters. The DataSet and DataAdapters was created with 3.50.14. After upgrading to 4.85.35 I have CHANGED the daAES's Select/Insert/Update/DeleteCommand. None of the other DataAdapters commands has been changed since the CoreLab upgrade. The error seems to occur only on the Command that has been changed after the upgrade. It is still a little difficult to know exactly since it only happens once in a while (2 times since release of new version on friday).

UPDATE: The error happens randomly at all the places in the generated code where SelectCommand is set. I don't set SelectCommand in my own code that I know of (and I don't have the time to check it right now). At least this means that the differences in version between generation of commands is not the problem here.

Temporary "fix/workaround":

I have made a retry function in the Windows Service app so that the same code is run again after 3 seconds if it somehow fails. We have had numerous strange problems with the CoreLab component before too so this as been very helpful so far. The WebService app has no such function yet so end users of our frontend gets this exception from time to time.

StackTrace: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index\n
Addtitional Info: at System.Collections.ArrayList.RemoveAt(Int32 index)
at CoreLab.Common.GlobalComponentsCache.AddToGlobalList(IComponent component, String groupName)
at CoreLab.Common.DbCommandBase.set_Owner(Object value)
at ProTeria.DB.AESHandler.InitializeComponent() in E:\PROJECTS\dotNET\dotNET_2\DB\AESHandler.Designer.cs:line 615
by trygvelo
Fri 03 Oct 2008 10:59
Forum: dotConnect for MySQL
Topic: Timestamp and tableadapters (generated code)
Replies: 4
Views: 3607

Yes, this is probably ok (haven't tested) for a MySqlDataAdapter, but what if I use DataSet integrated TableAdapters?
by trygvelo
Wed 01 Oct 2008 09:47
Forum: dotConnect for MySQL
Topic: Timestamp and tableadapters (generated code)
Replies: 4
Views: 3607

Timestamp and tableadapters (generated code)

Hi,

I had a problem today that the tableadapter configuration wizard didn't generate the insertcommand. I have a timestamp column in my database which is declared "not null default current_timestamp" as per default MySQL behaviour. I did not want to include the timestamp column in my select/insert/update since the generated tableadapter automatically defines the column with "AllowDBNull = false". I do not want to specify a value myself when I add new rows to the datatable but I want MySQL to automatically insert the value.

I guess the wizard could not create the insertcommand since columns set to not null in the database was not included in the select statement.

My workaround right now is that I manually change the AllowDBNull value to true for all timestamp columns, but this a potential source for bugs later if I forget to do this after an update of the tableadapter generation.

Any chance of a setting specifically for timestamps to choose that they don't need to be included in the select but the insertcommand will still be created? OR if running MySQL in MaxDB mode I believe it will be closer to the ANSI SQL correct behaviour, timestamp is then similar to DateTime column and are not updated automatically unless specified to do so in the table definition like: "ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP"

Any thought about this issue?

PS. Right now I don't dare changing the MySQL mode to MaxDB and spend a lot of time checking every part of every system using MySQL here...
by trygvelo
Wed 01 Oct 2008 09:21
Forum: dotConnect for MySQL
Topic: Get actual values from DB after INSERT with TableAdapter
Replies: 3
Views: 3943

Thanks, I'll look into it.
by trygvelo
Tue 23 Sep 2008 07:18
Forum: dotConnect for MySQL
Topic: Get actual values from DB after INSERT with TableAdapter
Replies: 3
Views: 3943

Get actual values from DB after INSERT with TableAdapter

Hi,

with a strongly typed dataset, how do I get the actual values (f.ex auto_increment, timestamp columns) from the database after an INSERT with TableAdapters.

* The "Refresh the data table" Advanced TableAdapter configuration option does not work. Bug? Missing feature?
* Temporarily I have tried to solve this by creating a custom property PublicAdapter in the dataset.cs class (not overwritten by dataset generation) that exposes the TableAdapters DataAdapter. Then I use the RowUpdated eventhandler of the DataAdapter to process each updated row and fetch the actual values from DB. My problem here is that I can't check that the RowState of the recently updated row is RowState.Added because after the update it is set to "RowState.Unchanged". How do I work around this so that I don't refresh both inserted and updated rows with data from db?

Any more elegant ways of doing this???

Best regards,
Trygve
by trygvelo
Wed 17 Sep 2008 08:48
Forum: dotConnect for MySQL
Topic: Run trial of 4.85 with licensed 3.50 on the same computer?
Replies: 1
Views: 2114

Run trial of 4.85 with licensed 3.50 on the same computer?

Hi,
'
can I install the 4.85 trial version while still having 3.50 licensed installed? It's been 5 business days since I paid for the upgrade from version 3 to version 4 but I still haven't got it so I was thinking I should just start working with the trial version until I got the licensed product.

Best regards,
Trygve Lorentzen (license is in my bosses name, Torstein Helling).
by trygvelo
Mon 16 Jan 2006 10:36
Forum: dotConnect for MySQL
Topic: 2 very annoying problems with 3.20.6 for .NET 2
Replies: 2
Views: 2692

2 very annoying problems with 3.20.6 for .NET 2

Hi, the most annoying problem I have is that every time I change some properties in a dataset created by MySQL DataAdapters it pops up a dialog with the question: "Do you want to regenerate Parameters collection for ". Since I have quite a lot of DataAdapters each with 4 sql statements, I get A LOT of these in a row... Mouseclicking olympics here I come... :evil: And I don't even want to regenerate the Parameters collection...

The second issue I have is with the Design Time Command Generator for DataAdapter. The generated sql update and delete statements adds all the UpdatingFields selected to the where clause, the way I see it only KEY FIELDS should be added to the where clause. Please correct! Beside from that I must say I like that you now give the generated parameters a good name: Original_ID f.ex. instead of just p1, p2 etc.

Please correct these problems quick!

Trygve
by trygvelo
Wed 19 Jan 2005 10:59
Forum: dotConnect for MySQL
Topic: DataSet contains more columns. BUG?
Replies: 1
Views: 3023

DataSet contains more columns. BUG?

Hi,

I'm using the latest (2.70) version of the MySQL Direct .NET connector. Discovered something I believe is not correct behaviour today. I have a dataadapter with a select statement like:

SELECT * FROM table

The corresponding datatable in the dataset is however not defined with all the columns that the SQL returns. When I use the dataset designtime it seems to be correct and the columns that are not defined in the dataset is not there, but at runtime those columns have automatically been added to the datatable. Is this correct behaviour?

Regards,
Trygve Lorentzen