Megafoon-2.00.zip


#1

Hoi Germ,

Ik heb net megafoon-2.00.zip op mijn anonieme ftp server (www.foonsearch.com) gezet. Mijn eerste indruk is dat het lekker snel werkt.

Deze versie zou ook bij jou kunnen werken op MySQL (database foondump2004).

Het zou nog fout kunnen gaan op de “opties”. Deze worden in de registery opgeslagen. Echter ik heb nog geen tijd gehad om het op een schoon systeem te kunnen testen. Volgens RGJ zet je deze info in de registery. Persoonlijk zou ik het in een config tabel van MySQL zetten, maar dit ter zijde.

Het leest ook de tows tabel in. Ik denk dat deze al standaard wordt aangemaakt bij het “Foondump dumpen” in MySQL. Je hoeft dan de bijgevoegde SQL bestanden niet gebruiken.

Germ, Laat even weten of het bij jou ook werkt.

De vriendelijke groet Jan Marco

P.S. Ik heb weer de routine er in gezet om een megafoon.ini automatisch aan te laten maken in de huidige directory. Deze kan je nadat je het de eerste keer hebt opgestart, de host, password, etc veranderen om naar MySQL te gaan.


#2

Hoi Germ,

Op mijn laptop (Windows XP professional) krijg ik een error nadat ik een query heb gedaan. Een of andere MFC error die hij naar Microsoft wil opsturen.

Het is mij wel gelukt om via deze laptop naar mijn andere windows pc te gaan om de gegevens te benaderen.

Ik zal wel het programma moeten laten termineren als je mysql niet kan bereiken.

De vriendelijke groet Jan Marco


#3

Hoi Germ,

Hierbij megafoon-2.01.zip op mijn ftp server gezet.

Als hij mysql niet kan bereiken dan geeft hij nu een fatale foutmelding.

De vriendelijke groet Jan Marco


#4

Hoi Germ,

De nieuwste versie Megafoon-2.02.zip werkt op mijn laptop (XP professional) —)

Ik deed een fclose(fp) op een niet geopende file. Was nog oude code die er niet goed uitgehaald was geworden.

Gaarne deze versie testen --)

De vriendelijke groet Jan Marco


#5

gaan we doen!

Germ


#6

Download gaat vlot en zonder problemen.
Installatie via aanklikken megafoon.exe

programma werkt (statusbalk: Megafoon verzie 2.02 …)

via opties locatie CDFOON bestanden gewist (pakt locatie welke in “oude” megafoon stond)

programma zoekt perfect en zeer snel in de mysql dump

Opmerking:
automatisch aanvullen van de plaatsen / namen werkt niet (weet niet of dit mogelijk is)

Verder in eerste instantie geen opmerkingen / problemen. Lijkt direct perfect te werken.

Germ


#7

Hoi Germ,

Verder in eerste instantie geen opmerkingen / problemen. Lijkt direct perfect te werken.

Erg bedankt voor jouw testresultaten --)

via opties locatie CDFOON bestanden gewist (pakt locatie welke in “oude” megafoon stond)

Werkt m.i. niet zo. Hij gaat direct naar tcp-ip poort van MySQL server via (in Visual C) meegelinkt MySQL routines.

Bijvoorbeeld de max zoektijd wordt wel in registery opgeslagen (als je op opties opslaan klikt) alleen nog niet aan MySQL query meegegeven.

Het gesorteerd laten zien op scherm kan m.i. ook gemakkelijk in MySQL worden uitgevoerd. Het sorteren van records op scherm werkt ook niet meer.

programma zoekt perfect en zeer snel in de mysql dump

M.i. erg afhankelijk of er keys/indexen op staan. Anders krijg je een table scan en dan zal je zeker niet blij worden van de zoektijden.

automatisch aanvullen van de plaatsen / namen werkt niet (weet niet of dit mogelijk is)

Niet moeilijk er in te programmeren. Als je op straat klikt zonder plaats te hebben gekozen moet je de records van streets in laten meegeven (m_cmbCity.AddString (row[0]) )

Als je een plaats hebt gekozen dan zou alleen die straten van de gekozen plaats moeten worden getoond.

Ik weet niet hoe je zo’n list box weer kan leeggooien als je achter een plaats komt. (m_cmbCity.ClearString (row[0]); ???)

De vriendelijke groet Jan Marco

Appendix A: Alle onafhankelijke straten op de Cdfoon:

DROP TABLE IF EXISTS streets;
create table streets (
streetname varchar(64) not null,
primary key (townname)
) type=myisam;

insert into streets select distinct streetname from town_street;


#8

Jan marco,

nog even wat gespeelt met Megafoon;

  • helaas kan ik geen delen van namen meer invullen. Wanneer ik “mak” invul, krijg ik alleen de naam Mak, en geen Makkinga, Makken, of Makelaardij … etc.
    Is het te realiseren dat er op een deel van de naam gezocht kan worden, via mysql / megafoon of een aloude dos opdracht “Mak*”

vr gr.

germ


#9

Hoi Germ,

Bedankt voor jouw test resultaten —)

nog even wat gespeelt met Megafoon;

Heb ik ook gedaan. Zag dat sommige records herhaald worden. Mogelijk is het aantal records gelijk aan het aantal info records. Ik heb het een beetje snel omgezet zonder goed uit te zoeken of het goed werkt. M.i. kan je nog goed uitleven om optimalisatieslagen in Megafoon aan te brengen. Denk aan het kunnen klikken op hyperlinks, etc.

  • helaas kan ik geen delen van namen meer invullen. Wanneer ik “mak” invul, krijg ik alleen de naam Mak, en geen Makkinga, Makken, of Makelaardij … etc.

Is het te realiseren dat er op een deel van de naam gezocht kan worden, via mysql / megafoon of een aloude dos opdracht “Mak*”

Je kan in MySQL gaan zoeken op {where like } statement. Bijvoorbeeld
Select * from phonenumbers where phonenumber like ‘05343400%’;

In stel voor dat je in de zoekveld iets intoetst met % er achter. In de select statement moet dat goed worden omgezet. Meer algemeen geformuleerd is dat je zoveel functionaliteiten die standaard in MySQL zitten in de MFC GUI zou moeten inbouwen. Dus niet wiel weer gaan uitvinden.

Ik denk momenteel na over om een extra zoek veld onderaan in Megafoon te positioneren. Deze zoekveld zou gelijksoortig aan een zoekveld in een search engine moeten werken. Je toets een woord in met AND of OR of NOT logica en hij gaat de entries teruggeven die aan het zoekvoorschrift voldoen. Eigenlijk moet je de zoeklogica van een zoekengine gaan implementeren.

Mogelijk hetzelfde veld ook kunnen gebruiken om SQL statements in te kunnen toetsten. Wel even nadenken welke velden je pakt. Mijn voorkeur zou hebben de velden die ze ook in Megafoon hebben. Dus een vertaling naar de werkelijke velden moet ergens gemaakt worden.

Het voordeel is dat je MySQL datastructuur universeel maakt en een vertaling per land/provincie (Friesland bijvoorbeeld) kan maken.

De vriendelijke groet Jan Marco


#10

Ik ben het daar niet mee eens.

  • Megafoon moet database onafhankelijk kunnen zijn (worden)
  • Megafoon moet bruikbaar zijn voor mensen die geen SQL kennen

Ik denk dus meer aan de richting van een vinkje achter de achternaam waarmee men kan aangeven of men op het hele woord of op een deel wil zoeken.


#11

Werkt niet.

ben het met RGJ eens dat het meer meot worden gezocht in het "aanvinken"van mogelijkheden.
Op deze manier hou je het gebruik makkelijk en voor iedereen toegangkelijk / begrijpelijk

Germ


#12

Hoi Germ, RGJ,

Bedankt voor jullie terugkoppelingen —)

In stel voor dat je in de zoekveld iets intoetst met % er achter

Werkt niet.

Klopt, Heel veel dingen werken nog niet. Je zal het er wel in moeten programmeren. Een ander voorbeeld is dat als je een grote plaats hebt geselecteerd (bijvoorbeeld Amsterdam) je niet kan onderbreken. Je zal in de lus wel moeten checken of gebruiker wil stoppen met het laten zien van records.

ben het met RGJ eens dat het meer moet worden gezocht in het "aanvinken"van mogelijkheden.

Op deze manier hou je het gebruik makkelijk en voor iedereen toegankelijk / begrijpelijk

Niemand is tegen om het toegankelijk/begrijpelijk te maken voor end-users, maar het moet ook geen kerstboom worden, waar je niet meer begrijpt wat je allemaal zou moeten aanvinken en aanklikken.

N.B. Met het aanvinken alleen ben je er namelijk niet. Want je zal toch moeten aangeven waar je de variatie toestaat.

Je kan namelijk ook op meerdere plaatsen toestaan:

Select * from phonenumbers where phonenumber like ‘ 053%43400%’;

M.i. ontkom je niet aan het gebruik van een aparte teken, waarom dan ook nog iets moeten aanvinken???

RGJ, Misschien kan Weerman als onze “Internet opzoek deskundige” hier iets zinnigs over zeggen —)

De vriendelijke groet Jan Marco


#13

[quote=“alkema_jm”]Select * from phonenumbers where phonenumber like ‘ 053%43400%’;

M.i. ontkom je niet aan het gebruik van een aparte teken, waarom dan ook nog iets moeten aanvinken???[/quote]

Je ontkomt prima aan het gebruik van een apart teken.

  1. Jan Marco, mensen die niet gewend zijn om DOS of SQL te gebruiken (en dat zijn er een hoop) snappen het fenomeen wildcard niet goed.

  2. Wanneer wildcards mogelijk zijn blijkt dit niet uit de user interface. Ik kan niet ruiken dat ik ergens een % kan plaatsen.

Indien je een vinkje opneemt achter de naam dan is het duidelijk.
Zie bv
http://www.bartportal.com/cgi-bin/portal/cdfoon.p

  1. De query 053%43400% is a) onzinnig en b) dodelijk voor de systeembelasting van de SQL server.

a) onzinnig want je wilt hooguit op nummerreeksen zoeken (bv ik bel vanaf nummer 0101236376 en jij vindt dit niet in het telefoonboek omdat mijn bedrijf de hele 01012363xx reeks heeft. Dan kan je op 0101236% zoeken en dan vind je me toch. Dat komt omdat een nummerreeks gekenmerkt wordt door identieke begincijfers.

Een query als 053%43400 heeft geen semantische betekenis.

b) Met wildcards in het midden kunnen geen indexen gebruikt worden.

In een nieuwere versie van fs2004 gebruik ik voor achternamen altijd default like ‘naam%’ en voor telefoonnummers ook, indien er minder dan 10 cijfers staan. Je hoeft dan nooit iets te vinken of te wildcarden. Works like a charm. Bartportal doet ook zoiets, je moet dan vinken als je het NIET wilt.

Groeten
RGJ


#14

Hoi RGJ,

Misschien handig om een extra tabel te maken van alle woorden in het fullname kolom. Op deze nieuwe tabel kunnen zoeken gelijksoortig aan een zoekengine.

De vriendelijke groet Jan Marco


#15

[quote=“rgj”]3) De query 053%43400% is a) onzinnig en b) dodelijk voor de systeembelasting van de SQL server.

a) onzinnig want je wilt hooguit op nummerreeksen zoeken (bv ik bel vanaf nummer 0101236376 en jij vindt dit niet in het telefoonboek omdat mijn bedrijf de hele 01012363xx reeks heeft. Dan kan je op 0101236% zoeken en dan vind je me toch. Dat komt omdat een nummerreeks gekenmerkt wordt door identieke begincijfers.

Een query als 053%43400 heeft geen semantische betekenis.

b) Met wildcards in het midden kunnen geen indexen gebruikt worden.[/quote]

Op 053%43400 zal inderdaad niet veel gezocht worden, maar er kan wel van een index gebruik gemaakt worden. Mysql zal de index op het telfoonnummer gebruiken om alleen die rijen te bekijken die met 053 beginnen. Niet veel anders dus als jouw default van ‘user-input%’. Nu zal het met 053 nog een aanslag op de sql server zijn, maar daar heeft zo’n default ook last van.

wat is het voordeel van zo’n extra tabel t.o.v. de huidige situatie?


#16

Hoi Xim,

wat is het voordeel van zo’n extra tabel t.o.v. de huidige situatie?

Je hebt o.a. twee kolommen last name en full name. In Megafoon-2.02.zip zoek ik op Last name en toon de Full name in kolom “Naam”.

Full name kan van alles zijn om een “woninginrichting” aan te duiden. Gechargeerd Full name voorbeeld “We zijn de gekste zaak van Nederland die stereo spullen verkoopt”. Je hebt dan geen specifieke last name. Een echt voorbeeld 0800-0227422 “Hypotheek Informatiecentrum Nederland HIN”. Is hier Lastname HIN? N.B. Nog niet opgezocht.

Je ziet ook wel varianten als “Kinderopvang Ukkie”, “Ukkie Kinderopvang”, “Kinderdagverblijf Ukkie” en “Ukkie Kinderdagverblijf” (gekunsteld voorbeeld uit 055 5424503). In Megafoon vind je “Kinderdagverblijf Ukkie” niet met zoekwoord “Ukkie” als Last name.

Even uitgelegd als analogie. Je zou de records ook kunnen zien als files. Je kan op files zoeken op de file attributen {(creation date, file name, etc) , (= “last name, Postcode, etc” in cdfoon termen)} maar je zou ook kunnen gaan zoeken in de inhoud van de file (“full name”)

De vriendelijke groet Jan Marco


#17

Hoi Xim,

Stel je hebt hetzelfde bedrijf met meerdere entries in de cdfoon. Om beter te kunnen worden gevonden betaald men daar vaak voor.

Recordnummer,Telefoonnummer, Full Name, Postcode:

1, 0800-0227422, “Hypotheek Informatiecentrum Nederland HIN”, 7316 EB
2, 0800-0227422, “HIN Hypotheek Informatiecentrum Nederland”, 7316 EB
3, (055) 541 07 93 , “Kinderdagverblijf Ukkie”, 7335 DN
4, (055) 541 07 93 , “Kinderopvang Ukkie”, 7335 DN
5, (055) 541 07 93 , “Ukkie Kinderopvang”, 7335 DN
6, (055) 541 07 93 , “Ukkie Kinderdagverblijf”, 7335 DN

Zou je ook kunnen omzetten naar:

Recordnummer, Telefoonnummer, Full Name, Postcode
1, 0800-0227422, “Hypotheek Informatiecentrum Nederland HIN|HIN Hypotheek Informatiecentrum Nederland”, 7316 EB
2, (055) 541 07 93 , “Kinderopvang Ukkie|Ukkie Kinderopvang|Kinderdagverblijf Ukkie|Ukkie Kinderdagverblijf”, 7335 DN
3, verwijderd
4, verwijderd
5, verwijderd
6, verwijderd

Seachengine tabel (Woord, Recordnummer dat hij voorkomt):

HIN, 1
Hypotheek, 1
Informatiecentrum, 1
Kinderdagverblijf, 2
Kinderopvang, 2
Nederland, 1
Ukkie, 2

Xim, Als jij een beter voorstel hebt dan hoor ik dat graag —)

De vriendelijke groet Jan Marco


#18

Ik had de fullname en lastname kolommen ff door elkaar gehaald, ik zie nu wel wat je met die extra tabel wil.

Ik heb wel zo m’n twijfels over het aanpassen van de data, dus het samenvoegen van rijen.

Mijn ervaring is dat het probleem altijd bij bedrijven zit en wat mij betreft is het het niet waard om in het witte gedeelte daar uitgebreid aandacht aan te besteden. Dat is meer iets voor het pink gedeelte en is daar het probleem van dubbele vermeldingen niet al opgelost met die MD5 hash?


#19

Hoi Xim,

Erg bedankt voor jouw terugkoppeling --)

Eerst even zeggen dat het mogelijk veranderen van database records gezien moet worden als scripts die je op de gedumpte foondump database kan uitvoeren.

Foondump zou gewoon de informatie moeten dumpen in MySQL. Extra controle checks en optimalisatie slagen lijkt mij onwenselijk. Dump proces duurt al lang genoeg.

Ik zie een MFC scherm voor mij waar bijvoorbeeld een “postcode check” script staat. Als je hierop klikt worden de databases die je hebt aangeklikt gecheckt/aangevuld met PostcodePro controle info.

Ik had de fullname en lastname kolommen ff door elkaar gehaald, ik zie nu wel wat je met die extra tabel wil.

Ik zie het meer strategisch. Het zoeken op “search engine” methode gaat in de toekomst meer naar toe gewerkt worden.

Ik heb wel zo m’n twijfels over het aanpassen van de data, dus het samenvoegen van rijen.

Mijn ervaring is dat het probleem altijd bij bedrijven zit en wat mij betreft is het het niet waard om in het witte gedeelte daar uitgebreid aandacht aan te besteden. Dat is meer iets voor het pink gedeelte en is daar het probleem van dubbele vermeldingen niet al opgelost met die MD5 hash?

-De MD5 hask zit gelukkig niet meer in het nieuwe database ontwerp van Pink.

-Misschien de bedrijven uit white halen en alleen in pink laten terugkomen.

Ik ben momenteel van mening dat je de functionaliteit van Megafoon een beetje zoals nu zou moeten laten verder ontwikkelen. Andere functionaliteiten maar in andere applicaties (capimonitor.exe, foonsearch.exe) stoppen.

Capimonitor gelijksoortig aan Megafoon maken. Als je een caller id krijgt die niet in de cdfoon staat dan met een MySQL insert deze in de foondump2004 kunnen stoppen, nadat je handmatige de info erbij hebt ingetoetst. N.B. Iets meer extra functionaliteit (“updaten records”) als Megafoon.

Hierna Foonsearch.exe maken door nieuwe records te gaan synchroniseren op Internet. Ik zal gnunet (http://www.gnu.org/software/gnunet/) source gebruiken om hiervoor iets te maken. N.B. Weer iets meer functionaliteit als Megafoon en Capimonitor (Namelijk tonen, aanvullen en synchroniseren van records).

De vriendelijke groet Jan Marco


#20

Jawel, kijk maar eens naar meisjesnamen in vermeldingen.

[quote]Dat is meer iets voor het pink gedeelte en is daar het probleem van dubbele vermeldingen niet al opgelost met die MD5 hash?

-De MD5 hask zit gelukkig niet meer in het nieuwe database ontwerp van Pink.[/quote]
Ik zie het ‘gelukkig’ niet zo. Maar het probleem met dubbele vermeldingen is wel opgelost.

Zoals ik al vaker heb gezegd ben ik fel tegen het veranderen van gedumpte data. ‘Verrijken’ van data en extra indexen etc aanmaken ok, maar ik wil niets gaan veranderen. Dan moet je namelijk aannames doen over de data, en dat gaat veel te vaak fout.