Forums

PHP

This topic is locked

PHAkt & move to specific record

Posted 04 Sep 2001 16:06:23
1
has voted
04 Sep 2001 16:06:23 Jochem Peppelenbos posted:
Hi there,

I'm completely new to PHP, so my mind is overloaded with questions right now. I won't bother you with all of them, just with one, for a start <img src=../images/dmxzone/forum/icon_smile_wink.gif border=0 align=middle>. I know how to work wit Ultradev, ASP and VB. Unfortunately, my works ISP only supports PHP, my boss doesn't want to move to another ISP and so I have to learn about PHP as well. So fortunately I found PHAkt, the setup was fine, my DB connections are fine. I converted an Access DB into MySQL, works fine. The repeat region server behaviour works fine... But then, when I want to move to a specific record, something really strange happens. The URL parameter is "id", the DB field is "FId", I set this up just as I used to do with UD and ASP (server behaviour). But it doesn't work? If I ask for FId=1 with index.php?id=1, I get record number 2. When I ask for id=2, I get FId=4, id=3 leads to FId=7... id=30 -&gt; FId=59! But there IS an FId 1, 2, 3, etc... In ASP this worked, what am I doing wrong? Does anyone know? I'm only using the UD Server behaviours with PHAkt, I didn't change any code myself!

Thanks,
Gompy.

Replies

Replied 04 Sep 2001 19:53:33
04 Sep 2001 19:53:33 Tim Green replied:
I've had this problem myself, though the solution isn't immediately apparent.

When you convert an Access database to a MySQL database, certain translations etc occur which are inevitable.

After a lot of investigation when this happened for me, I found that the translation hadn't been entirely perfect in that the unique id (in your case the Fid) wasn't being correctly assigned as an AutoIncrement Index field.

Unfortunately when this happens there are all sorts of unpredictable results, so I would recommend that you use a tool such PHPMyAdmin, or MySQL Front to make sure that Unique Fields, Index Fields and AutoIncrement Fields have been properly translated. Where they are wrong fix that, and hopefully this should sort out your problem.

Tim Green

Extension & PHP TalkZone Manager
<font size=1>-------------------------------------------
<i>Please read the Forum FAQ before posting
a question to this TalkZone.</i>
-------------------------------------------
www.UDzone.com : A dynamic Dreamweaver,
Ultradev and Fireworks site for developers
by developers.
-------------------------------------------</font id=size1>
Replied 04 Sep 2001 21:17:44
04 Sep 2001 21:17:44 Jochem Peppelenbos replied:
Hi Tim,

thanks for your answer. You are indeed right, something is wrong with my tables. I didn't notice this before because as I said, I'm a newbie, I'm used to the "luxery" (and dramas) of MS Access and wow, then MySQL is something to get used to. Anyway, I converted my MS Access database with a convertion wizard of Intelligent Converters. Only the first 5 records were converted properly, because when I browse with PHPMyAdmin, those are the only records shown. There should be about 60 records in this table. However, if I browse this table with my PHP-page, I do get to see other records than the first five, although it is always a record that I didn't ask for, as I described earlier. A repeat region of all records leads to a neat list with ALL the records. I'm getting kind of lost here and I assume that either the indexes or the tables are corrupt. What would you advise? What's the best way to convert Access DB's to MySQL? Exporting in MS Access to ODBC leads to the mysterious error message "record is too large" (not telling me which record on earth it is talking about). Are there other conversion methods or ways to get my "ghost" records back?

Thanks,
Gompy.
Replied 04 Sep 2001 22:25:14
04 Sep 2001 22:25:14 Tim Green replied:
I would personally recommend that you export all of your data from access in CSV format.

Then, unfortunately, comes the hard bit. You have to recreate the whole of your database structure in MySQL. The problem is that many translation programs don't correctly translate field types, and I suspect that the translation software you are using is taking a 'Memo' field and translating it as a MySQL VARCHAR(255) field (which of course only gives you 255 characters) instead of a TEXT field.

Using PHPMyAdmin to build tables in this way can be a bit laborious, so I would suggest that you use a piece of Freeware called MySQL Front (www.mysqlfront.de), which allows you to easily create your tables, and import your CSV data straight into the tables.

It makes life a whole lot easier.

I hope this helps.

Tim Green

Extension & PHP TalkZone Manager
<font size=1>-------------------------------------------
<i>Please read the Forum FAQ before posting
a question to this TalkZone.</i>
-------------------------------------------
www.UDzone.com : A dynamic Dreamweaver,
Ultradev and Fireworks site for developers
by developers.
-------------------------------------------</font id=size1>
Replied 04 Sep 2001 22:31:51
04 Sep 2001 22:31:51 Jochem Peppelenbos replied:
So you are actually saying that MySQL can handle fields larger than 255 characters?

Gompy.

Replied 04 Sep 2001 22:41:51
04 Sep 2001 22:41:51 Tim Green replied:
Absolutely. MySQL has full support for BLOB's (Binary Large Objects), so if you wanted to you can store whole files in a table field.

A TEXT field, is essentially a BLOB, but it allows you to store far more than 255 characters.

Tim Green

Extension & PHP TalkZone Manager
<font size=1>-------------------------------------------
<i>Please read the Forum FAQ before posting
a question to this TalkZone.</i>
-------------------------------------------
www.UDzone.com : A dynamic Dreamweaver,
Ultradev and Fireworks site for developers
by developers.
-------------------------------------------</font id=size1>
Replied 04 Sep 2001 22:51:27
04 Sep 2001 22:51:27 Jochem Peppelenbos replied:
Wow, so maybe my forced switch to PHP + MySQL is not such a bad thing after all... For this same database (a FAQ management system) with ASP, I had to write many extra lines of VB script in order to split text in fields of 255 chars and later on combine them again. As I understand it now, I don't have to do this again for PHP, that makes it a lot easier!

Anyway, first I'll try to get a good working database the way you described it. Thanks for your help, I'll let you know if it worked.

Gompy.

Replied 04 Sep 2001 22:57:20
04 Sep 2001 22:57:20 Tim Green replied:
Yep, you'll find the PHP/MySQL combination quite a powerful one.

Let me know how you get on, and welcome to the Community.

All the best

Tim Green

Extension & PHP TalkZone Manager
<font size=1>-------------------------------------------
<i>Please read the Forum FAQ before posting
a question to this TalkZone.</i>
-------------------------------------------
www.UDzone.com : A dynamic Dreamweaver,
Ultradev and Fireworks site for developers
by developers.
-------------------------------------------</font id=size1>
Replied 05 Sep 2001 23:18:42
05 Sep 2001 23:18:42 Jochem Peppelenbos replied:
Okay... I'm getting kind of tired of everything already <img src=../images/dmxzone/forum/icon_smile_wink.gif border=0 align=middle> Ehm, MySQL Front does not want to take more than 50 characters into a TEXT or MEDIUMTEXT field. Others seem to have this problem as well, according to the forum at mysqlfront.de, .CSV export leads to a mess, I tried every separator and line terminator, eh... Is there other software that I could try?

Thanks,
Gompy.
Replied 06 Sep 2001 13:07:33
06 Sep 2001 13:07:33 Tim Green replied:
Hmmm. For CSV export you only need access.

As far as MySQLFront is concerned, I don't know what the current version is, but I'm using v1.18Beta, and I have just entered 800 characters into a TEXT field without problem.

If you want this version of MySQL Front I will happily send it to you.

Tim Green

Extension & PHP TalkZone Manager
<font size=1>-------------------------------------------
<i>Please read the Forum FAQ before posting
a question to this TalkZone.</i>
-------------------------------------------
www.UDzone.com : A dynamic Dreamweaver,
Ultradev and Fireworks site for developers
by developers.
-------------------------------------------</font id=size1>
Replied 07 Sep 2001 00:04:15
07 Sep 2001 00:04:15 Jochem Peppelenbos replied:
Hi Tim,

I already found version 1.18beta and u r rite, I can at least enter more than 50 chars now. But CSV import still leads to a huge mess. Anyway, I think I'll juct copy all data by hand because this is taking too much time, and besides that, due to the fact that MySQL has these BLOB/TEXT fields and better DATE/TIME fields, I want to change the structure of the tables anyway. However, thanks for your help!

Gompy.
Replied 07 Sep 2001 12:46:13
07 Sep 2001 12:46:13 Tim Green replied:
You've probably made a better decision recreating your tables and data from scratch, as now you can really benefit from MySQL's inherent optimizations, which don't necssarily work when converting from one db type to another.

Always glad to be of help. <img src=../images/dmxzone/forum/icon_smile.gif border=0 align=middle>

Tim Green

Extension & PHP TalkZone Manager
<font size=1>-------------------------------------------
<i>Please read the Forum FAQ before posting
a question to this TalkZone.</i>
-------------------------------------------
www.UDzone.com : A dynamic Dreamweaver,
Ultradev and Fireworks site for developers
by developers.
-------------------------------------------</font id=size1>
Replied 09 Sep 2001 14:38:27
09 Sep 2001 14:38:27 Jochem Peppelenbos replied:
Hey Tim thanks a lot, I have rebuilt my database and now it works fine. I do have another problem now though, but I posted that as a new topic...

Gompy.

Reply to this topic